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.
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.
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.
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]$
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".
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.
I added the patch to the master branch today. Should show up in rawhide tomorrow. I'll look at updating F18 later today.
Added the patch to F18 today.
Verified (again) with 3.8.2-201.fc18.x86_64 on Dell XPS 8500. mokutil --disable-validation and mokutil --enable-validation both work.