[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