** 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 + 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. + + 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. + - 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1604873 Title: MokSBStateRT strictly inferior to /proc/sys/kernel/moksbstate_disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1604873/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs