[ClusterLabs] The latest shim from Leap 15.4 disallows shim from Tumbleweed and possibly other distributions
Andrei Borzenkov
arvidjaar at gmail.com
Sat Apr 1 03:31:16 EDT 2023
https://forums.opensuse.org/t/after-a-shim-update-yesterday-no-longer-able-to-boot-with-secure-boot-enabled/165382/16
https://bugzilla.opensuse.org/show_bug.cgi?id=1209985
To explain.
There is relatively new standard SBAT which makes it possible to "mass
blacklist" EFI binaries supporting it. In rough overview, each binary
carries a "generation" number which is increased when vulnerability is
fixed. System has SbatLevel EFI variable which lists minimal accepted
generations. Any binary which has smaller generation is rejected (by
shim). What is important is that shim also verifies itself when starting.
That is the general theory. Now comes implementation - there is no tool
to manage SbatLevel variable directly - it is written by shim itself! At
best you can select between two different values ("previous" and
"latest") or reset this variable to some initial value. What "previous"
and "latest" contain is entirely up to shim developers/maintainers.
Initial value is empty.
What happened now was the following
1. Leap 15.4 shim fixed some CVE and increased its own generation
2. Current Leap shim automatically enforces "latest" content of
SbatLevel during installation which now requires at least shim generation 2
3. shim in Tumbleweed on one hand supports SBAT, on the other hand it
has too old generation and so refuses to run.
It also means that once you booted current Leap 15.4 shim at least once,
you can no more to boot any installation image that includes shim new
enough to understand SBAT but old enough to have generation 1 (like
current Ubuntu shim :) ) with Secure Boot enabled. It will simply turn
system off after showing error message.
It is possible to mitigate it by using
mokutil --set-sbat-policy previous
*before* updating to the new shim. In this case new shim will set
embedded previous policy that does only lists grub2.
Initial policy after reset (empty, only header):
sbat,1,2021030218
Policy after rebooting into new shim with "previous" set:
sbat,1,2022052400
grub,2
Policy after rebooting with new shim after default installation
(implicit "latest"):
sbat,1,2022111500
shim,2
grub,3
As you see, even "previous" adds minimal grub requirement which may
block grub from other distributions (all to protect you of course :) ).
What is *NOT* possible is to tell shim to leave SbatLevel the hell alone
on *my* system.
Frankly the implementation looks like security theater to me, but I am
not security expert ...
More information about the Users
mailing list