[Bug 1604873] Re: MokSBStateRT strictly inferior to /proc/sys/kernel/moksbstate_disabled

[Steve Langasek]

** Description changed:

  [SRU Justification]
  In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system.  As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
  
  [Test case]
  1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
- 2. Create the /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 variable with a value of 1 XXX: figure out how to do this
+ 2. As root, run "printf '\x07\x00\x00\x00\x01' > /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23".
  3. Install shim-signed from -updates.
  4. Install the dahdi-dkms package.
  5. Confirm that you are not prompted to disable secureboot.
  6. Install shim-signed from -proposed.
  7. Confirm that you *are* prompted to disable secureboot.
- 8. Delete the /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 variable.
- 
+ 8. Run 'sudo rm /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'.
  
  update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state.  However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information.  There are two that it tries to use:
   - We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
   - The recent kernels which honor MokSBState also include support for exposing this value as  /proc/sys/kernel/moksbstate_disabled.
  
  Neither of these is guaranteed to be present on any given system.
  However, if present, the kernel variable should be *unconditionally*
  preferred over the efi "shadow" variable - because the kernel variable
  is immutable, whereas MokSBStateRT is just another nvram variable that
  things can overwrite (though they shouldn't).
  
  We have heard at least one report internally of a system where something
  other than our shim is setting the value of MokSBStateRT and confusing
  update-secureboot-policy, so this will be a priority to also fix in SRU.

** Description changed:

  [SRU Justification]
  In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system.  As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.
  
  [Test case]
  1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
  2. As root, run "printf '\x07\x00\x00\x00\x01' > /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23".
  3. Install shim-signed from -updates.
  4. Install the dahdi-dkms package.
  5. Confirm that you are not prompted to disable secureboot.
  6. Install shim-signed from -proposed.
  7. Confirm that you *are* prompted to disable secureboot.
  8. Run 'sudo rm /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'.
  
+ [Regression potential]
+ Since /proc/sys/kernel/moksbstate_disabled will not be present on older kernels, and /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 is always less authoritative than /proc/sys/kernel/moksbstate_disabled if present, I don't see any way that this could regress.
+ 
  update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state.  However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information.  There are two that it tries to use:
   - We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
-  - The recent kernels which honor MokSBState also include support for exposing this value as  /proc/sys/kernel/moksbstate_disabled.
+  - The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.
  
  Neither of these is guaranteed to be present on any given system.
  However, if present, the kernel variable should be *unconditionally*
  preferred over the efi "shadow" variable - because the kernel variable
  is immutable, whereas MokSBStateRT is just another nvram variable that
  things can overwrite (though they shouldn't).
  
  We have heard at least one report internally of a system where something
  other than our shim is setting the value of MokSBStateRT and confusing
  update-secureboot-policy, so this will be a priority to also fix in SRU.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to shim-signed in Ubuntu.
https://bugs.launchpad.net/bugs/1604873

Title:
  MokSBStateRT strictly inferior to /proc/sys/kernel/moksbstate_disabled

Status in shim-signed package in Ubuntu:
  Fix Released
Status in shim-signed source package in Precise:
  New
Status in shim-signed source package in Trusty:
  New
Status in shim-signed source package in Wily:
  New
Status in shim-signed source package in Xenial:
  New

Bug description:
  [SRU Justification]
  In some cases, incorrect locally-set EFI variables can prevent the shim-signed package from detecting that SecureBoot is active on the system.  As a result, the user will not be prompted to disable SecureBoot, and will be left with non-functional dkms modules after reboot to the new kernel.

  [Test case]
  1. Install Ubuntu on a system (or VM) with SecureBoot enabled.
  2. As root, run "printf '\x07\x00\x00\x00\x01' > /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23".
  3. Install shim-signed from -updates.
  4. Install the dahdi-dkms package.
  5. Confirm that you are not prompted to disable secureboot.
  6. Install shim-signed from -proposed.
  7. Confirm that you *are* prompted to disable secureboot.
  8. Run 'sudo rm /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23'.

  [Regression potential]
  Since /proc/sys/kernel/moksbstate_disabled will not be present on older kernels, and /sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23 is always less authoritative than /proc/sys/kernel/moksbstate_disabled if present, I don't see any way that this could regress.

  update-secureboot-policy tries to check whether MOK's override has disabled SecureBoot state.  However, since the real variable in nvram is not accessible after boot, it needs to use a proxy for this information.  There are two that it tries to use:
   - We've specified how shim can mirror the MokSBState variable to MokSBStateRT at boot time, to expose this information to the OS (but this is not implemented in current shim).
   - The recent kernels which honor MokSBState also include support for exposing this value as /proc/sys/kernel/moksbstate_disabled.

  Neither of these is guaranteed to be present on any given system.
  However, if present, the kernel variable should be *unconditionally*
  preferred over the efi "shadow" variable - because the kernel variable
  is immutable, whereas MokSBStateRT is just another nvram variable that
  things can overwrite (though they shouldn't).

  We have heard at least one report internally of a system where
  something other than our shim is setting the value of MokSBStateRT and
  confusing update-secureboot-policy, so this will be a priority to also
  fix in SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1604873/+subscriptions