"Could not acquire EC lock" with kernel 5.3.0-24

[linkwh]

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" #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]

After a bit of tinkering, the workaround works again. I don't know what broke it momentarily!

[linkwh]

The issue is back... The workaround doesn't work anymore!

guillaume@massada:~$ uname -a
Linux massada 5.3.0-24-generic #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
guillaume@massada:~$ cat /opt/lift_kernel_lockdown.sh 
#!/bin/bash -ex

DEFAULT_SYSRQ=$(sysctl -n kernel.sysrq)
sysctl -w kernel.sysrq=1
echo x > /proc/sysrq-trigger
sysctl -w kernel.sysrq=${DEFAULT_SYSRQ}

guillaume@massada:~$ sudo /opt/lift_kernel_lockdown.sh 
++ sysctl -n kernel.sysrq
+ DEFAULT_SYSRQ=176
+ sysctl -w kernel.sysrq=1
kernel.sysrq = 1
+ echo x
+ sysctl -w kernel.sysrq=176
kernel.sysrq = 176
guillaume@massada:~$ nbfc.exe start
EC initialization failed: Could not acquire EC lock

I guess something has changed in a recent kernel update (?).

[linkwh]

I do confirm this has to do with a recent kernel update!

Fresh boot with kernel 5.3.0-24 :

guillaume@massada:~$ uname -a
Linux massada 5.3.0-24-generic #26-Ubuntu SMP Thu Nov 14 01:33:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
guillaume@massada:~$ sudo systemctl status lift-kernel-lockdown.service 
● lift-kernel-lockdown.service - Disable kernel lockdown feature
   Loaded: loaded (/etc/systemd/system/lift-kernel-lockdown.service; enabled; ve
   Active: inactive (dead) since Tue 2019-12-17 19:27:35 CET; 1min 13s ago
  Process: 986 ExecStart=/opt/lift_kernel_lockdown.sh (code=exited, status=0/SUC
 Main PID: 986 (code=exited, status=0/SUCCESS)
déc. 17 19:27:35 massada systemd[1]: Starting Disable kernel lockdown feature...
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: ++ sysctl -n kernel.sysrq
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: + DEFAULT_SYSRQ=176
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: + sysctl -w kernel.sysrq=
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: kernel.sysrq = 1
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: + echo x
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: + sysctl -w kernel.sysrq=
déc. 17 19:27:35 massada lift_kernel_lockdown.sh[986]: kernel.sysrq = 176
déc. 17 19:27:35 massada systemd[1]: lift-kernel-lockdown.service: Succeeded.
déc. 17 19:27:35 massada systemd[1]: Started Disable kernel lockdown feature.
guillaume@massada:~$ nbfc.exe start
EC initialization failed: Could not acquire EC lock

Fresh boot with kernel 5.3.0-23 :

guillaume@massada:~$ uname -a
Linux massada 5.3.0-23-generic #25-Ubuntu SMP Tue Nov 12 09:22:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
guillaume@massada:~$ sudo systemctl status lift-kernel-lockdown.service 
● lift-kernel-lockdown.service - Disable kernel lockdown feature
   Loaded: loaded (/etc/systemd/system/lift-kernel-lockdown.service; enabled; ve
   Active: inactive (dead) since Tue 2019-12-17 19:30:35 CET; 47s ago
  Process: 1009 ExecStart=/opt/lift_kernel_lockdown.sh (code=exited, status=0/SU
 Main PID: 1009 (code=exited, status=0/SUCCESS)
déc. 17 19:30:35 massada systemd[1]: Starting Disable kernel lockdown feature...
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: ++ sysctl -n kernel.sysr
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: + DEFAULT_SYSRQ=176
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: + sysctl -w kernel.sysrq
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: kernel.sysrq = 1
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: + echo x
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: + sysctl -w kernel.sysrq
déc. 17 19:30:35 massada lift_kernel_lockdown.sh[1009]: kernel.sysrq = 176
déc. 17 19:30:35 massada systemd[1]: lift-kernel-lockdown.service: Succeeded.
déc. 17 19:30:35 massada systemd[1]: Started Disable kernel lockdown feature.
guillaume@massada:~$ nbfc.exe start
guillaume@massada:~$

[linkwh]

See : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380?comments=all

[YtvwlD]

I have replied in #414. I should probably have done this here. Sorry.

[jgoclawski]

@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: #472 (comment)

[YtvwlD]

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]

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]

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]

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]

I just have a question for the kernel module: how we should expose the EC file? Through /dev/ec or anything else?

[saidsay-so]

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]

@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]

It should be trivial to write a new plugin, I think I can handle it myself. Thanks for the help though!

[YtvwlD]

@musikid I just took a quick look at your install.sh and the stuff eg. the virtualbox package for Ubuntu does. I think the following should be enough:

update-secureboot-policy --new-key # this won't do anything if one already exists
update-secureboot-policy --enroll-key # this should pop up a wizard guiding the key enrollment process
dkms add -m $MODULE_NAME -v "$VERSION"
dkms install -m $MODULE_NAME -v "$VERSION" # dkms will sign the module automatically

[saidsay-so]

@YtvwlD It seems that update-secureboot-policy is only available on Ubuntu while mokutil appears to be on most distributions that can be installed with SecureBoot (at least on Ubuntu and Fedora). What a pity!

[YtvwlD]

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]

@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]

Yeah sure, a PR would be great!

[saidsay-so]

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 that ec_sys is 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_sys module doesn't work with Secure Boot enabled 😕 .

[github-actions]

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]

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]

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.