This bug was fixed in the package shim-signed - 1.18~12.04.1
---------------
shim-signed (1.18~12.04.1) precise; urgency=medium
* update-secureboot-policy: If /proc/sys/kernel/moksbstate_disabled is
present, prefer this unconditionally over MokSBStateRT. LP: #1604873.
-- Steve Langasek <[email protected]> Wed, 20 Jul 2016
16:22:42 -0700
** Changed in: shim-signed (Ubuntu Precise)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Released
Status in shim-signed source package in Trusty:
Fix Released
Status in shim-signed source package in Wily:
Fix Released
Status in shim-signed source package in Xenial:
Fix Released
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
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : [email protected]
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
