[GH-ISSUE #414] [Fedora 27] EC initialization failed: Could not acquire EC lock

kerem commented

2026-02-26 00:32:27 +03:00

Owner

Originally created by @FloChehab on GitHub (Dec 28, 2017).
Original GitHub issue: https://github.com/hirschmann/nbfc/issues/414

Hi,

I was previously on fedora 26 and nbfc was working well.
Yesterday, I updated to fedora 27 and suddenly nbfc stopped working.

I tried reinstalling it from the last release : unsuccessful.
I removed everything, updated mono, and reinstalled from master:

the service is starting
NbfcServiceLog.txt
service_status.txt
but when I do sudo mono nbfc.exe config --apply "Asus Zenbook UX410UQ" I am getting the EC initialization failed: Could not acquire EC lock error.

I am running Fedora 27 / Linux Kernel 4.14.8-300 on my Asus Zenbook UX410UQ.

NB : nbfc is working great on the same computer with windows.

Any idea on solving this issue ? Any more details needed ?

Originally created by @FloChehab on GitHub (Dec 28, 2017). Original GitHub issue: https://github.com/hirschmann/nbfc/issues/414 Hi, I was previously on fedora 26 and nbfc was working well. Yesterday, I updated to fedora 27 and suddenly nbfc stopped working. I tried reinstalling it from the last release : unsuccessful. I removed everything, updated mono, and reinstalled from `master`: - the service is starting [NbfcServiceLog.txt](https://github.com/hirschmann/nbfc/files/1591044/NbfcServiceLog.txt) [service_status.txt](https://github.com/hirschmann/nbfc/files/1591045/service_status.txt) - but when I do `sudo mono nbfc.exe config --apply "Asus Zenbook UX410UQ"` I am getting the `EC initialization failed: Could not acquire EC lock` error. I am running Fedora 27 / Linux Kernel 4.14.8-300 on my Asus Zenbook UX410UQ. NB : nbfc is working great on the same computer with windows. Any idea on solving this issue ? Any more details needed ?

kerem closed this issue

2026-02-26 00:32:27 +03:00

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@mandree commented on GitHub (Dec 28, 2017):

same here, where strace -f reveals this around the error message when running sudo strace -f mono ec-probe.exe dump 2>&1:

[pid 29558] openat(AT_FDCWD, "/sys/kernel/debug/ec/ec0/io", O_RDWR|O_EXCL) = -1 EPERM (Operation not permitted)
[pid 29558] write(2, "messages.c: A message was found "..., 79messages.c: A message was found on the uncommon code path: 1 - Invalid function) = 79
[pid 29558] ioctl(1, TCGETS, 0x7fff329a6b90) = -1 ENOTTY (Inappropriate ioctl for device)
[pid 29558] write(2, "Could not acquire EC lock\n", 26Could not acquire EC lock) = 26

$ uname -r
4.14.8-300.fc27.x86_64

@mandree commented on GitHub (Dec 28, 2017): same here, where strace -f reveals this around the error message when running ```sudo strace -f mono ec-probe.exe dump 2>&1```: ``` [pid 29558] openat(AT_FDCWD, "/sys/kernel/debug/ec/ec0/io", O_RDWR|O_EXCL) = -1 EPERM (Operation not permitted) [pid 29558] write(2, "messages.c: A message was found "..., 79messages.c: A message was found on the uncommon code path: 1 - Invalid function) = 79 [pid 29558] ioctl(1, TCGETS, 0x7fff329a6b90) = -1 ENOTTY (Inappropriate ioctl for device) [pid 29558] write(2, "Could not acquire EC lock\n", 26Could not acquire EC lock) = 26 ``` ``` $ uname -r 4.14.8-300.fc27.x86_64 ```

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@mandree commented on GitHub (Dec 28, 2017):

I found this in my dmesg output:

[ 1293.192283] Lockdown: debugfs is restricted; see man kernel_lockdown.7

I do not have that manual page, but figured this:
Apparently this is a result of "kernel lockdown" that restricts access to the kernel debug configuration in context with UEFI Secure Boot, with these links:

@mandree commented on GitHub (Dec 28, 2017): I found this in my ```dmesg``` output: ``` [ 1293.192283] Lockdown: debugfs is restricted; see man kernel_lockdown.7 ``` I do not have that manual page, but figured this: Apparently this is a result of "kernel lockdown" that restricts access to the kernel debug configuration in context with _UEFI Secure Boot,_ with these links: - https://firmwaresecurity.com/2017/10/19/linux-kernel-lockdown-patch/ - https://lkml.org/lkml/2017/10/5/215 <- **draft manual page explaining the rationale** - https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down - https://docs.fedoraproject.org/f27/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader.html

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@mandree commented on GitHub (Dec 28, 2017):

based on https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=47a04d29e952d4dd896f2ec4c2ecee6971ab364d the workaround is:

sudo sysctl -w kernel.sysrq=1 
sudo sh -c 'echo x >/proc/sysrq-trigger'
sudo sysctl -w kernel.sysrq=16

which lifts the kernel lockdown and then restores the Fedora default sysrq mask allowing only Magic SysRq+S for sync devices. Note that this reduces security since kernel image modifications and other new safety defenses are then down. I do not oversee the consequences.

After this, mono nbfc.exe start will work again.

@mandree commented on GitHub (Dec 28, 2017): based on https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=efi-lock-down&id=47a04d29e952d4dd896f2ec4c2ecee6971ab364d the workaround is: ``` sudo sysctl -w kernel.sysrq=1 sudo sh -c 'echo x >/proc/sysrq-trigger' sudo sysctl -w kernel.sysrq=16 ``` which lifts the kernel lockdown and then restores the Fedora default sysrq mask allowing only Magic SysRq+S for _sync devices_. Note that this reduces security since kernel image modifications and other new safety defenses are then down. I do not oversee the consequences. After this, ```mono nbfc.exe start``` will work again.

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@FloChehab commented on GitHub (Dec 28, 2017):

@mandree
Thank you for your quick reply ! I didn't get all your explanations (I am not a Linux expert) but your solution is effective.

Do you know if there are any tweaks that can be done on nbfc side's ? If not, I'll close the issue.

Thanks again and have good day.

@FloChehab commented on GitHub (Dec 28, 2017): @mandree Thank you for your quick reply ! I didn't get all your explanations (I am not a Linux expert) but your solution is effective. Do you know if there are any tweaks that can be done on nbfc side's ? If not, I'll close the issue. Thanks again and have good day.

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@FloChehab commented on GitHub (Dec 29, 2017):

After a restart the patch wasn't working anymore (it certainly could have been redone).
I recently did a BIOS update that reactivated Secure Boot without telling it.

After disabling secure boot, everything is back to normal.

@FloChehab commented on GitHub (Dec 29, 2017): After a restart the patch wasn't working anymore (it certainly could have been redone). I recently did a BIOS update that reactivated Secure Boot without _telling_ it. After disabling secure boot, everything is back to normal.

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@jgoclawski commented on GitHub (Mar 4, 2018):

@mandree thanks for investigating and sharing your findings!

To make the change persistent I've created a simple systemd service. That way the kernel lockdown is lifted at every boot, before nbfc service starts.

/etc/systemd/system/lift-kernel-lockdown.service:

[Unit]
Description=Disable kernel lockdown feature
Before=nbfc.service

[Service]
ExecStart=/opt/lift_kernel_lockdown.sh
Type=oneshot

[Install]
WantedBy=multi-user.target

/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}

@jgoclawski commented on GitHub (Mar 4, 2018): @mandree thanks for investigating and sharing your findings! To make the change persistent I've created a simple systemd service. That way the kernel lockdown is lifted at every boot, before nbfc service starts. /etc/systemd/system/lift-kernel-lockdown.service: ``` [Unit] Description=Disable kernel lockdown feature Before=nbfc.service [Service] ExecStart=/opt/lift_kernel_lockdown.sh Type=oneshot [Install] WantedBy=multi-user.target ``` /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} ```

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@stefanocirici commented on GitHub (May 10, 2018):

@jgoclawski With your script, is the kernel lockdown restored after running the nbfc service?

@stefanocirici commented on GitHub (May 10, 2018): @jgoclawski With your script, is the kernel lockdown restored after running the nbfc service?

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@mandree commented on GitHub (May 13, 2018):

No, @jgoclawski 's script will only reinstate the prior Magic SysRq settings, but the lockdown remains lifted.

@mandree commented on GitHub (May 13, 2018): No, @jgoclawski 's script will only reinstate the prior Magic SysRq settings, but the lockdown remains lifted.

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@stefanocirici commented on GitHub (May 14, 2018):

Is there a way to restore it after being lifted?

@stefanocirici commented on GitHub (May 14, 2018): Is there a way to restore it after being lifted?

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@jgoclawski commented on GitHub (May 15, 2018):

If you restore the lockdown (I'm not sure if it's possible), nbfc would stop working, because it needs to poll EC periodically. So it's either nbfc with disabled lockdown or nbfc not working and lockdown enabled.

@jgoclawski commented on GitHub (May 15, 2018): If you restore the lockdown (I'm not sure if it's possible), nbfc would stop working, because it needs to poll EC periodically. So it's either nbfc with disabled lockdown or nbfc not working and lockdown enabled.

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@stefanocirici commented on GitHub (May 15, 2018):

Ok. I got it

@stefanocirici commented on GitHub (May 15, 2018): Ok. I got it

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@linkwh commented on GitHub (Dec 17, 2019):

The issue is back with kernel 5.3.0-24.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380?comments=all and https://github.com/hirschmann/nbfc/issues/800

@linkwh commented on GitHub (Dec 17, 2019): The issue is back with kernel 5.3.0-24. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851380?comments=all and https://github.com/hirschmann/nbfc/issues/800

kerem commented

2026-02-26 00:32:27 +03:00

Author

Owner

@YtvwlD commented on GitHub (Dec 18, 2019):

Hi, I'm the reporter of the Ubuntu bug @linkwh linked.

This behaviour did exploit a bug in Ubuntu's lockdown implementation. It should defend the kernel against attacks from root - it should obviously not be able for root to simply disable it. This is already fixed in Ubuntu and newer upstream kernels. I didn't report this bug to other distros yet.

I was asked whether there is a better way. And yes, there are solutions to this that don't expose the whole kernel to root.

* This project's kernel module could use DKMS. This could make use of the MOK workflow already present in Ubuntu.
* This project's kernel module could be included in the upstream kernel.

The last option would be more secure, but more difficult to achieve.

I didn't look at the source code yet (and I don't know any C#). If anyone could explain to me how this software interfaces with the kernel I can probably recommend something (although I'm not really an expert).

@YtvwlD commented on GitHub (Dec 18, 2019): Hi, I'm the reporter of the Ubuntu bug @linkwh linked. This behaviour did exploit a bug in Ubuntu's lockdown implementation. It should defend the kernel against attacks from root - it should obviously not be able for root to simply disable it. This is already fixed in Ubuntu and newer upstream kernels. I didn't report this bug to other distros yet. I was asked whether there is a better way. And yes, there are solutions to this that don't expose the whole kernel to root. * This project's kernel module could use DKMS. This could make use of the MOK workflow already present in Ubuntu. * This project's kernel module could be included in the upstream kernel. The last option would be more secure, but more difficult to achieve. I didn't look at the source code yet (and I don't know any C#). If anyone could explain to me how this software interfaces with the kernel I can probably recommend something (although I'm not really an expert).

Rows
Columns

[GH-ISSUE #414] [Fedora 27] EC initialization failed: Could not acquire EC lock #372