Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Can't disable Secure Boot with MokSBState|
|Product:||[Fedora] Fedora||Reporter:||Lingzhu Xiang <lxiang>|
|Component:||kernel||Assignee:||Kernel Maintainer List <kernel-maint>|
|Status:||CLOSED ERRATA||QA Contact:||Lingzhu Xiang <lxiang>|
|Version:||18||CC:||caiqian, fedora, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mjg59|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-04-03 13:58:09 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Lingzhu Xiang 2013-02-04 05:09:15 EST
Description of problem: Shim includes a feature (MoK) to allow physically present users to disable or circumvent Secure Boot through a consistent UI without having to frob firmware settings. Shim stores user consent securely with variable MokSBState. When MokSBState is 1, shim and grub skips signature verification. But kernel only reads variable SecureBoot and ignores MokSBState. So even if the user wants to disable Secure Boot with mok, kernel will still boot in Secure Boot mode with access locked down and features disabled. Variable SecureBoot is read-only per spec. Shim can't change this. Version-Release number of selected component (if applicable): kernel-3.7.4-204.fc18 (vmlinuz signature stripped) How reproducible: Always Steps to Reproduce: (Secure Boot Standard Mode in firmware) 1. mokutil --disable-validation input password (8~16 characters): input password again: 2. reboot 3. Press Down and Enter in shim menu to change secure boot state Shim UEFI key management Continue boot >Change Secure Boot state 4. Enter three password characters. 5. Press y and Enter to confirm disabling Secure Boot. 6. Press any key to reboot system (reboot) Actual results: Shim displays "Booting in insecure mode" for one second. Shim loads unsigned grub. Grub loads unsigned kernel. Kernel has Secure Boot enabled. dmesg | grep Secure [ 0.000000] Secure boot enabled Expected results: Kernel has Secure Boot not enabled.
Comment 1 Josh Boyer 2013-02-04 11:00:11 EST
Matthew, we discussed this in IRC a while ago with Thorsten, but we didn't really resolve whether the kernel should be looking at this variable on boot. I can see reasoning for both ignoring it and honoring it, so I'm curious what your thoughts are.
Comment 2 Matthew Garrett 2013-02-04 11:18:42 EST
I don't think there's any harm in disabling it, but the kernel would have to ensure that the variable doesn't have the runtime attribute set.
Comment 3 Josh Boyer 2013-02-05 19:32:27 EST
Created attachment 693597 [details] Patch to not enable secure boot mode if MokSBState is set This patch seems to work on my Tunnel Mountain box. I have SecureBoot still set, and SetupMode as 0, which means the firmware thinks the box is in SB mode. However the kernel read MokSBState and booted into insecure mode. [jwboyer@localhost efivars]$ hexdump -C SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 00000000 17 00 00 00 01 |.....| 00000005 [jwboyer@localhost efivars]$ hexdump -C SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c 00000000 17 00 00 00 00 |.....| 00000005 [jwboyer@localhost efivars]$ dmesg | grep -i secure [jwboyer@localhost efivars]$
Comment 4 Lingzhu Xiang 2013-02-05 22:47:09 EST
The patch works with 3.8.0-0.rc6.git2.1.fc19 on Dell XPS 8500. SecureBoot is 1; SetupMode is 0; dmesg doesn't have "Secure boot enabled".
Comment 5 Thorsten Leemhuis 2013-02-06 02:20:29 EST
Ohh, good, the topic came up again, as I had planed to discuss it some more anyway :-) (In reply to comment #3) > Created attachment 693597 [details] > Patch to not enable secure boot mode if MokSBState is set Looks good and I'm all for applying, because this introduces a way to get rid of the downsides Secure Boot has in Fedora that doesn't force the users to enter the firmware/bios setup. But in addition, what went trough my head is this: If shim isn't validating anything, shouldn't it already tell the firmware about it (by calling exitBootServices or something like that)? Because in the current situation (without the patch from josh) the kernel and it's users assume there is a chain of trust, when actually there isn't if you disabled validation in shim.
Comment 6 Josh Boyer 2013-02-06 09:24:44 EST
I added the patch to the master branch today. Should show up in rawhide tomorrow. I'll look at updating F18 later today.
Comment 7 Josh Boyer 2013-02-11 11:19:10 EST
Added the patch to F18 today.
Comment 8 Lingzhu Xiang 2013-03-06 05:38:06 EST
Verified (again) with 3.8.2-201.fc18.x86_64 on Dell XPS 8500. mokutil --disable-validation and mokutil --enable-validation both work.