Bug 907406

Summary: Can't disable Secure Boot with MokSBState
Product: [Fedora] Fedora Reporter: Lingzhu Xiang <lxiang>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Lingzhu Xiang <lxiang>
Severity: high Docs Contact:
Priority: high    
Version: 18CC: fedora, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mjg59, qcai
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-03 17:58:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to not enable secure boot mode if MokSBState is set none

Description Lingzhu Xiang 2013-02-04 10:09:15 UTC 
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 16:00:11 UTC 
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 16:18:42 UTC 
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-06 00:32:27 UTC 
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-06 03:47:09 UTC 
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 07:20:29 UTC 
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 14:24:44 UTC 
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 16:19:10 UTC 
Added the patch to F18 today.
Comment 8 Lingzhu Xiang 2013-03-06 10:38:06 UTC 
Verified (again) with 3.8.2-201.fc18.x86_64 on Dell XPS 8500.

mokutil --disable-validation and mokutil --enable-validation both work.