Bug 1599197 - kernel lockdown breaks too much for me
Summary: kernel lockdown breaks too much for me
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 28
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-07-09 07:54 UTC by Jason Haar
Modified: 2019-09-26 20:27 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-07-09 08:49:14 UTC

Attachments (Terms of Use)
disable lockdown in dracut before resume via sysrq trigger (992 bytes, patch)
2019-09-26 20:27 UTC, Thomas Meyer
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1638874 None NEW efi-lockdown status needs to be exposed to userspace 2019-10-28 17:31:13 UTC

Internal Links: 1638874

Description Jason Haar 2018-07-09 07:54:15 UTC
Description of problem:

Hi there

Since installing F28 on a new laptop and (apparently) mistakenly choosing UEFI boot instead of old BIOS-mode, I've had a couple of problems

My existing Brother USB printer can no longer be controlled via "scanimage" from sane-backends. That generates a "Lockdown: scanimage: ioperm is restricted; see man kernel_lockdown.7" kernel error

...and just now I went to try out wireguard - a "next gen" VPN solution which has a kernel module. They have a repo for installing it, but it's "wireguard-dkms" built-on-the-fly kernel module fails to load with "Lockdown: modprobe: Loading of unsigned module is restricted" too

"sane-backends" actually comes from Fedora-updates, so frankly Fedora should have enabled "ioperm" to work, and I guess you'd argue Wireguard should somehow figure out how to digitally sign their kernel modules (via dkms? I'd think those two are mutually exclusive?), but as a end-user this is all "too hard" for me (like selinux) - so I just want to shoot it in the head

Can you tell me how I can disable this lockdown "feature"? Some exotic kernel-hack is *not* how my system is going to get hacked - I don't want my system to be military-grade secure if that means I can't do the things I want to do on it

So any hint would be appreciated. Google doesn't seem to find instructions for me (I'm hoping you're not going to say I have to reinstall :-(



Comment 1 Matthew Garrett 2018-07-09 08:49:14 UTC
You can disable lockdown by disabling secure boot - run

sudo mokutil --disable-validation

and reboot, and then follow the prompts. However, please open a bug against sane-backends - drivers for USB devices shouldn't be calling ioperm(). I'll close this bug since this is working as intended from the kernel's perspective, but thanks for the report of the breakage.

Comment 2 Jason Haar 2018-07-09 19:10:37 UTC
I ran the mokutil command from the console as root and had to enter a password? I made one up and afterwards rebooted. However - there are no "prompts"...

I am running F28 as a server - non-GUI. I assume these "prompts" are GUI-only? Also the wireguard module failed to load: "modprobe: Loading of unsigned module is restricted" - so Lockdown is still in place

Any more hints please :-)


Comment 3 Matthew Garrett 2018-07-09 19:19:26 UTC
The prompts are provided in the system firmware, so if it's a headless device you'll need to use the remote console to confirm them.

Comment 4 Jason Haar 2018-07-09 20:08:43 UTC
Wow - I see what you mean. That did the trick. After the reboot and weird password challenges I got to disable secureboot and then it came up properly - and now I can load the wireguard kernel module :-)



Comment 5 Thomas Meyer 2019-09-20 21:05:20 UTC
For the record you can disable kernel lockdown via sys-rq:
sudo bash -c 'echo 1 > /proc/sys/kernel/sysrq'
sudo bash -c 'echo x > /proc/sysrq-trigger'

Comment 6 Jan-Philip Gehrcke 2019-09-26 14:24:37 UTC
> For the record you can disable kernel lockdown via sys-rq:
> sudo bash -c 'echo 1 > /proc/sys/kernel/sysrq'
> sudo bash -c 'echo x > /proc/sysrq-trigger'

Thanks for the hint. Is this modification permanent / does it survive reboots? Where is this documented? Thank yoU!

Comment 7 Thomas Meyer 2019-09-26 20:26:05 UTC

no sadly above is not enough. in a running system, this enables the resume to hibernate to disk correctly, but once the system is powered on again and the kernel starts above steps needs to be done before trying to resume the image from disk again.
this is why I did patch dracut a bit. see attached patch.
this is just a hack, as my swap is encrypted anyway.

Comment 8 Thomas Meyer 2019-09-26 20:27:23 UTC
Created attachment 1619783 [details]
disable lockdown in dracut before resume via sysrq trigger

Note You need to log in before you can comment on or make changes to this bug.