Bug 907406 - Can't disable Secure Boot with MokSBState
Summary: Can't disable Secure Boot with MokSBState
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Lingzhu Xiang
Depends On:
TreeView+ depends on / blocked
Reported: 2013-02-04 10:09 UTC by Lingzhu Xiang
Modified: 2013-07-04 20:56 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-04-03 17:58:09 UTC
Type: Bug

Attachments (Terms of Use)
Patch to not enable secure boot mode if MokSBState is set (1.76 KB, text/plain)
2013-02-06 00:32 UTC, Josh Boyer
no flags Details

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:

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                                    |.....|
[jwboyer@localhost efivars]$ hexdump -C SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c 
00000000  17 00 00 00 00                                    |.....|
[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.

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