** 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 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
