mirror of
https://github.com/hirschmann/nbfc.git
synced 2026-04-25 16:45:53 +03:00
[GH-ISSUE #800] "Could not acquire EC lock" with kernel 5.3.0-24 #702
Labels
No labels
Stale
bug
config
discussion
duplicate
enhancement
experimental
feature
help-wanted
info
invalid
invalid
pull-request
question
up-for-grabs
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nbfc-hirschmann#702
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @linkwh on GitHub (Dec 9, 2019).
Original GitHub issue: https://github.com/hirschmann/nbfc/issues/800
Looks like an odd coincidence as the bug was closed yesterday...
But the problem described here : "'Could not acquire EC lock' on Ubuntu 18.04 LTS" https://github.com/hirschmann/nbfc/issues/472
is back with kernel 5.3.0-24-generic (at least on Ubuntu).
The workaround described doesnt work anymore and NBFC cannot start.
@linkwh commented on GitHub (Dec 9, 2019):
After a bit of tinkering, the workaround works again. I don't know what broke it momentarily!
@linkwh commented on GitHub (Dec 17, 2019):
The issue is back... The workaround doesn't work anymore!
I guess something has changed in a recent kernel update (?).
@linkwh commented on GitHub (Dec 17, 2019):
I do confirm this has to do with a recent kernel update!
Fresh boot with kernel 5.3.0-24 :
Fresh boot with kernel 5.3.0-23 :
@linkwh commented on GitHub (Dec 17, 2019):
See : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380?comments=all
@YtvwlD commented on GitHub (Dec 18, 2019):
I have replied in #414. I should probably have done this here. Sorry.
@jgoclawski commented on GitHub (Dec 18, 2019):
@YtvwlD hey, thanks for dropping by. Let's continue here, because the other issue is closed.
More background from the author can be found in this comment: https://github.com/hirschmann/nbfc/issues/472#issuecomment-388073176
@YtvwlD commented on GitHub (Dec 18, 2019):
Thank you for pointing me to the relevant portion of the code.
This seems to be a conceptual issue: You can't directly access hardware from userspace anymore. You'll need to have a small kernel module that exposes that small bit of functionality you actually need.
Edit: This project seems to be built on the promise to access the EC OS-independent in user-space. One workaround I could think of is adding a kernel module that exposes just the embedded controller without validating anything. This would still decrease the security a bit but much less than lifting lockdown.
@saidsay-so commented on GitHub (Feb 29, 2020):
Is there another solution apart from the kernel module? In case it's the only one, I started working on a small module which basically take most of its code from
ec_sys.c. I just worked to make it build as an out-of-tree kernel module. The only constraint which comes with this is that it needs the user to manually generate keys for the module or at least approve them if we sign the module.@YtvwlD commented on GitHub (Feb 29, 2020):
Well, yes. But the last part is being (partly) being handled by (some?) distributions, see eg. https://wiki.ubuntu.com/UEFI/SecureBoot for Ubuntu.
So, if you build this module with DKMS, the system will automatically generate a MOK, sign the module with it and give the user instructions on how to enroll the key.
@saidsay-so commented on GitHub (Feb 29, 2020):
Didn't knew that we can generate keys on the fly. If it's the case, then it should be trivial to make it work with DKMS.
@saidsay-so commented on GitHub (Feb 29, 2020):
I just have a question for the kernel module: how we should expose the EC file? Through
/dev/ecor anything else?@saidsay-so commented on GitHub (Mar 2, 2020):
I finally finished to write the kernel module (here). However, I don't know how to modify NBFC so it doesn't access directly to
/dev/port. All the low-level access code has to be replaced.@hirschmann commented on GitHub (Mar 4, 2020):
@MusiKid
Thank you very much for creating a DKMS module! Thats really awesome :)
To add support for your kernel module to NBFC, you have to create an EC plugin.
Fortunately there is already a plugin for ec_sys (see StagWare.Plugins.ECSysLinux), so you could basically copy the project and change the sysfs file path and the Initialize() method.
Let me know if you need help writing a plugin for your module or if I should write the plugin for you.
@saidsay-so commented on GitHub (Mar 4, 2020):
It should be trivial to write a new plugin, I think I can handle it myself. Thanks for the help though!
@YtvwlD commented on GitHub (Mar 4, 2020):
@MusiKid I just took a quick look at your
install.shand the stuff eg. the virtualbox package for Ubuntu does. I think the following should be enough:@saidsay-so commented on GitHub (Mar 4, 2020):
@YtvwlD It seems that
update-secureboot-policyis only available on Ubuntu whilemokutilappears to be on most distributions that can be installed with SecureBoot (at least on Ubuntu and Fedora). What a pity!@YtvwlD commented on GitHub (Mar 4, 2020):
Debian does, too. But yeah, there seems to be no automatic process for combining DKMS and Secure Boot on either Fedora or openSUSE - someone using one of those distros could probably open an issue there and ask for that.
@saidsay-so commented on GitHub (May 3, 2020):
@hirschmann I finally finished the module and the plug-in. I made the installation process of the module as simple as possible. Should I send a pull request?
@hirschmann commented on GitHub (May 4, 2020):
Yeah sure, a PR would be great!
@saidsay-so commented on GitHub (May 19, 2020):
I tested the module and it should work everywhere now. But, after diggging on other solutions than using an out-of-tree module which requires custom keys on distros other than Debian, I discovered thatec_sysis already available on a lot of distros without any modification to be made. The only thing to do is to just make it available at boot, which requires just a few lines of code. So, I think the best solution is just to add a guide to explain the solution. So, should I modify the wiki's FAQ to add a note for the users with Secure Boot ?Edit: I was too quick, the
ec_sysmodule doesn't work with Secure Boot enabled 😕 .@github-actions[bot] commented on GitHub (Nov 17, 2020):
This issue is stale because it has been open more than 180 days with no activity. If nobody comments within 7 days, this issue will be closed
@otterlistic commented on GitHub (Jun 30, 2021):
What's the status on this issue? Has any progress been made?
I do not want to disable secure boot, (it's not up to me) but I would like to use nbfc to control fan speeds. This still seems to be an issue with Ubuntu's current LTS version 20.0.04 on an Acer Nitro5.
@saidsay-so commented on GitHub (Aug 9, 2021):
I have written a module to circumvent this problem. I have also written an alternative to NBFC specifically for Linux, since it's rather hard to build it on this platform if anyone is interested.