The latest shim from Leap 15.4 disallows shim from Tumbleweed and possibly other distributions
https://forums.opensuse.org/t/after-a-shim-update-yesterday-no-longer-able-t... 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 ...
On 4/3/23 08:40, Andrei Borzenkov wrote:
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 ...
Sound like a total cluster-fsck if implemented at the EFI level for systems with multiple virtualized OS's to boot. Other than there being this gap (like the Ubuntu example that still had gen. 1 sbat), is this being fixed? What are companies that store virtualized images for backups (historical or otherwise) supposed to do if all of a sudden none of the saved VM's will boot due to a sbat cockup? -- David C. Rankin, J.D.,P.E.
participants (2)
-
Andrei Borzenkov
-
David C. Rankin