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

[Taihsiang Ho]

tested on 201508-18805 - Dell XPS 13 9350 - Dino 2 SKL with 14.04.4.
I could reproduce the test case, except that the step2 and the step8 would get "permission denied" and "operation not permitted" respectively.
There is no prompt at step5 and there is prompt at step7.

-- 
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:
  Fix Committed
Status in shim-signed source package in Trusty:
  Fix Committed
Status in shim-signed source package in Wily:
  Fix Committed
Status in shim-signed source package in Xenial:
  Fix Committed

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