Bugzilla – Bug 1209985
Secure boot violation when install Leap shim and Tumbleweed shim in one machine
Last modified: 2024-07-05 00:29:04 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Build Identifier: Booting today, I got a message: Something has gone wrong. Security violation. It mentioned "shim", so I assume it was problem with validating "shim.efi". The message goes past very quickly, so it is hard to get the exact wording. After that it shuts the system down. Microsoft Windows 8.1 still boots normally. However, I get this failure with both the Tumbleweed/openSUSE shim and with Leap/SUSE shim. Earlier today, I booted to Tumbleweed. That boot used the shim from Leap 15.4. I then updated Tumbleweed (previous update was 2 weeks earlier). On rebooting after that update, I ran into this problem. I'm suspecting that something happened during the update to cause this -- perhaps NVRAM corruption. But that's only a guess. Disabling secure-boot allows me to use the system again. Looking at various keys with "mokutil", I cannot see anything with a date that expires today. The problem might be hardware dependent. Secure-boot works as expected in a KVM virtual machine. Reproducible: Always
Can confirm that this also happens on openSUSE Leap 15.4 with all latest updates as of this current hour, including kernel and grub updates. Laptop is Acer Aspire 3 A315-58 released on 2021. Reproducible: Always (unless disabling secure boot in BIOS settings)
Exact error message: Verifying shim SBAT data failed: Security Policy Violation Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation Which appears right after BIOS's splash pic, but does not allow Grub to boot, and instead self shuts down immediately.
(In reply to Carlos Gonzalez from comment #2) > Exact error message: > > Verifying shim SBAT data failed: Security Policy Violation > Something has gone seriously wrong: SBAT self-check failed: Security Policy > Violation > > Which appears right after BIOS's splash pic, but does not allow Grub to > boot, and instead self shuts down immediately. Are you using multiboot? What openSUSE or other distributions are used?
There could be a problem in mixed environment. After booting the current Leap 15.4 shim (shim-15.7-150300.4.11.1.x86_64) the SbatLevel is set to bor@10:~> sudo cat /sys/firmware/efi/vars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23/data sbat,1,2022111500 shim,2 grub,3 bor@10:~> objcopy -j .sbat -O binary /usr/lib64/efi/shim.efi /dev/stdout sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim shim.sle,1,SUSE Linux Enterprise,shim,15.7,mail:security@suse.de bor@10:~> Leap 15.4 shim has version 3 so it will pass verification. But Tumbleweed shim remains on version 1 user@uefi:~> objcopy -O binary -j .sbat /usr/share/efi/x86_64/shim.efi /dev/stdout sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md shim,1,UEFI shim,shim,1,https://github.com/rhboot/shim shim.opensuse,1,The openSUSE project,shim,15.4,mail:security-team@suse.de user@uefi:~> Tumbleweed shim should not reset SbatLevel due to earlier date user@uefi:~> cat /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 sbat,1,2021030218 user@uefi:~> and so will fail self-verification according to configured policy. (In reply to Neil Rickert from comment #0) > > Earlier today, I booted to Tumbleweed. That boot used the shim from Leap > 15.4. I then updated Tumbleweed (previous update was 2 weeks earlier). On > rebooting after that update, I ran into this problem. I'm suspecting that > something happened during the update to cause this -- perhaps NVRAM > corruption. But that's only a guess. > > Disabling secure-boot allows me to use the system again. > Neil, could you please Show the current value of SbatLevelRT EFI variable 1. Make sure you are using Tumbleweed shim for booting 2. run on Tumbleweed mokutil --set-sbat-policy reset while secure boot is disabled. Then reboot. 3. If you will see MokManager requesting to confirm, do it. 4. Enable Secure Boot 5. Reboot again You should be able to boot into Tumbleweed. Check value of SbatLevelRT again.
It seems it is related to this change: https://bugzilla.suse.com/show_bug.cgi?id=CVE-2022-28737
(In reply to Andrei Borzenkov from comment #4) > mokutil --set-sbat-policy reset Sorry, it is "delete", not "reset".
Responding to c#5 Yes, that change looks to be the likely culprit. As a result, with secure-boot enabled, I cannot boot the Leap 15.4 install iso and I cannot boot Tumbleweed isos. To boot my installed Tumbleweed, I need to use the new shim from Leap 15.4. And to boot my installed Leap 15.3, I need to use the new shim from Leap 15.4. I probably cannot boot the Leap 15.5 Beta iso.
Responding to c#4: >Show the current value of SbatLevelRT EFI variable sbat,1,2022111500 shim 2 grub 3 I'm testing this on a different computer, so I am updating Tumbleweed first (I already updated Leap 15.4). When the update is complete, I'll try the other steps. This change looks like a mistake. In order to tighten secure-boot security they have made changes which force us to disable secure-boot. And that doesn't improve security.
A further response to c#4 >Show the current value of SbatLevelRT EFI variable sbat,1,2022111500 shim,2 grub,3 >mokutil --set-sbat-policy reset (I used "delete" rather than "reset") This did not do anything. Rebooting Tumbleweed left SbatLevelRT the same as above. So I tried again, but this time I booted with Leap 15.4 (and its shim). And this time for SbatLevelRT: sbat,1,2021030218 and now I could boot with secure-boot enabled and the Tumbleweed shim. Booting Leap 15.4 again, the SbatLevelRT was: sbat,1,2022052400 grub,2 and I could still boot with the Tumbleweed shim. Another boot of Leap 15.4, and no further changes. I'm guessing that the "set-sbat-policy" change requires MokManager action, and the MokManager with Tumbleweed is too old.
A colleage hit this exact issue after installing updates on a Lenovo laptop running (only) Leap 15.4. No custom kernel. The last update installation updated grub, but unless I somehow missed it in the zypp history, not shim. With SB disabled, the system booted fine and I ran: mokutil --set-verbosity true mokutil --set-sbat-policy delete This didn't fix it, MokManager hit the security violation as well, presumably before doing anything. I also cleared the EFI partition + bootorder and ran "shim-install" and "shim-install --removable --no-nvram" for good measure, no difference. For the time being SB had to be disabled.
We have not yet refreshed the shim for tumbleweed, which is at SBAT level 1. This is pending and WIP.
(In reply to Fabian Vogt from comment #10) > running (only) Leap 15.4 Please show efibootmgr -v ls -lR /boot/efi /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23 rpm -q shim For this to happen 1. new shim had to boot at least once to update SbatLevel 2. somehow old shim was used after that We need to find out where this old shim comes from.
[in reply to comment #12] sudo efibootmgr -v BootCurrent: 0019 Timeout: 0 seconds BootOrder: 0001,0000,0010,0011,0012,0013,0014,0017,0018,0019,001A,001B,001C,001D Boot0000* opensuse-secureboot HD(1,GPT,3fe41252-3fdc-476c-9520-034fd1bef10f,0x800,0x100000)/File(\EFI\opensuse\shim.efi) Boot0001* opensuse-secureboot HD(1,GPT,a6944199-4d90-4c5a-a920-70181216dea6,0x800,0x100000)/File(\EFI\opensuse\shim.efi) Boot0010 Setup FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9) Boot0011 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850) Boot0012 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380) Boot0013 Lenovo Diagnostics FvFile(3f7e615b-0d45-4f80-88dc-26b234958560) Boot0014 ThinkShield secure wipe FvFile(3593a0d5-bd52-43a0-808e-cbff5ece2477) Boot0015 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479) Boot0016 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5) Boot0017* USB CD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55) Boot0018* USB FDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49) Boot0019* NVMe0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,001c199932d94c4eae9aa0b6e98eb8a400) Boot001A* ATA HDD0 VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600) Boot001B* USB HDD VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803) Boot001C* PXE BOOT VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803) Boot001D Regulatory Information FvFile(478c92a0-2622-42b7-a65d-5894169e4d24) Boot001E* Boot Next Boot Option VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,a7ca6d35b2c2684783721826a7404894) ls -lR /boot/efi /boot/efi: total 4 drwxr-xr-x 4 root root 4096 Feb 1 14:03 EFI /boot/efi/EFI: total 8 drwxr-xr-x 2 root root 4096 Apr 3 08:47 boot drwxr-xr-x 2 root root 4096 Apr 3 08:44 opensuse /boot/efi/EFI/boot: total 3108 -rwxr-xr-x 1 root root 953800 Apr 3 08:47 bootx64.efi -rwxr-xr-x 1 root root 86352 Feb 1 14:03 fallback.efi -rwxr-xr-x 1 root root 203 Apr 3 08:47 grub.cfg -rwxr-xr-x 1 root root 1275904 Apr 3 08:47 grub.efi -rwxr-xr-x 1 root root 852408 Apr 3 08:47 MokManager.efi /boot/efi/EFI/opensuse: total 3416 -rwxr-xr-x 1 root root 58 Apr 3 08:47 boot.csv -rwxr-xr-x 1 root root 203 Apr 3 08:47 grub.cfg -rwxr-xr-x 1 root root 1275904 Apr 3 08:47 grub.efi -rwxr-xr-x 1 root root 401408 Apr 3 08:47 grubx64.efi -rwxr-xr-x 1 root root 852408 Apr 3 08:47 MokManager.efi -rwxr-xr-x 1 root root 953800 Apr 3 08:47 shim.efi rpm -q shim shim-15.7-150300.4.11.1.x86_64
> BootOrder: 0001,0000,0010,0011,0012,0013,0014,0017,0018,0019,001A,001B,001C,001D > Boot0000* opensuse-secureboot HD(1,GPT,3fe41252-3fdc-476c-9520-034fd1bef10f,0x800,0x100000)/File(\EFI\opensuse\shim.efi) > Boot0001* opensuse-secureboot HD(1,GPT,a6944199-4d90-4c5a-a920-70181216dea6,0x800,0x100000)/File(\EFI\opensuse\shim.efi) That looks a bit suspicious - why two entries with different partition GUID if there is only one ESP? lsblk says: nvme0n1 259:0 0 476.9G 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi └─nvme0n1p2 259:2 0 476.4G 0 part └─cr_nvme-WDC_PC_SN530_SDBPMPZ-512G-1001_21023T470222-part2 254:0 0 476.4G 0 crypt ├─system-swap 254:1 0 14.9G 0 lvm [SWAP] └─system-root 254:2 0 461.6G 0 lvm /var ... sgdisk --print /dev/nvme0n1 -i 1 says: Disk /dev/nvme0n1: 1000215216 sectors, 476.9 GiB Model: WDC PC SN530 SDBPMPZ-512G-1001 Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 7C56EC3D-4445-4A0C-999A-40FA74E15942 ... Number Start (sector) End (sector) Size Code Name 1 2048 1050623 512.0 MiB EF00 2 1050624 1000215182 476.4 GiB 8E00 Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI system partition) Partition unique GUID: A6944199-4D90-4C5A-A920-70181216DEA6 First sector: 2048 (at 1024.0 KiB) Last sector: 1050623 (at 513.0 MiB) Partition size: 1048576 sectors (512.0 MiB) Attribute flags: 0000000000000000 Partition name: '' so Boot0001 has the right GUID and is also the first in the BootOrder, so it should work. Question is where this weird Boot0000 is coming from. lsblk doesn't show any other block devices which might host another ESP.
And to add to the last comment Output of "blkid" and ""lsblk -f" would be useful What is the content of /sys/firmware/efi/efivars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
Oh, and what is the actual error in the first place? We may be facing entirely different issue here.
(In reply to Andrei Borzenkov from comment #16) > Oh, and what is the actual error in the first place? We may be facing > entirely different issue here. I made a screenshot of the initial error with verbose shim boot enabled. The main messages were: shim.sle, 1, ..., 15.4, mail:security-team@suse.de ... component shim, generation 1, was revoked by SbatLevel variable Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation Question is how the new shim was installed and executed at least once and later the old one took over again, from some mystery location.
Would you please also check the .sbat section of grub.efi ? For example, in the following case, because grub.efi(grub,1) < vars(grub,3), it will be revoked finally. > cat /sys/firmware/efi/vars/SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23/data sbat,1,2022111500 shim,2 grub,3 /boot/efi/EFI/opensuse> objdump -j .sbat -s grub.efi|more .sbat section： 127000 73626174 2c312c53 42415420 56657273 sbat,1,SBAT Vers 127010 696f6e2c 73626174 2c312c68 74747073 ion,sbat,1,https 127020 3a2f2f67 69746875 622e636f 6d2f7268 ://github.com/rh 127030 626f6f74 2f736869 6d2f626c 6f622f6d boot/shim/blob/m 127040 61696e2f 53424154 2e6d640a 67727562 ain/SBAT.md.grub 127050 2c312c46 72656520 536f6674 77617265 ,1,Free Software .......... finished verifying SBAT data: Security Policy Violation ���������������������������������������������������� � ERROR � � � � Verification failed: (0x1A) Security Violation � � � ����������������������������������������������������
(In reply to Fabian Vogt from comment #17) > (In reply to Andrei Borzenkov from comment #16) > > Oh, and what is the actual error in the first place? We may be facing > > entirely different issue here. > > I made a screenshot of the initial error with verbose shim boot enabled. The > main messages were: Attaching this screenshot would be better. Note that BootCurrent is 0019 which means firmware used "boot from NVMe" entry. In which case it loaded /boot/efi/EFI/boot/bootx64.efi. While this file itself looks OK, it loads fallback.efi and it looks old. objcopy -O binary -j .sbat /boot/efi/EFI/boot/bootx64.efi objcopy -O binary -j .sbat /boot/efi/EFI/boot/fallback.efi Still even if loading fallback.efi fails (it does for me) it should then try to load MokManager.efi. objcopy -O binary -j .sbat /boot/efi/EFI/boot/MokManager.efi Any chance that bootx64.efi and MolManager.efi were updated after the error was captured?
[in reply to #15] blkid /dev/mapper/system-swap: UUID="e2a1b8f2-6926-47ff-bca1-177fe34f2b3c" TYPE="swap" /dev/nvme0n1p1: UUID="2AF2-E83C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a6944199-4d90-4c5a-a920-70181216dea6" /dev/nvme0n1p2: UUID="365c60cb-ac6c-480f-9464-b62aedc54e03" TYPE="crypto_LUKS" PARTUUID="3565df54-e870-4c89-9c14-e0c5f1efd0fa" /dev/mapper/system-root: UUID="92760c3c-52e1-4cbb-9c64-2edc6f61cca6" UUID_SUB="703838b9-9956-4203-a23a-298ac11ea0f0" BLOCK_SIZE="4096" TYPE="btrfs" /dev/mapper/cr_nvme-WDC_PC_SN530_SDBPMPZ-512G-1001_21023T470222-part2: UUID="fcKmkV-QD9d-gfGU-kyaG-S7l6-iNAM-IBLmfF" TYPE="LVM2_member" lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS nvme0n1 │ ├─nvme0n1p1 │ vfat FAT32 2AF2-E83C 504.6M 1% /boot/efi └─nvme0n1p2 crypto 1 365c60cb-ac6c-480f-9464-b62aedc54e03 └─cr_nvme-WDC_PC_SN530_SDBPMPZ-512G-1001_21023T470222-part2 LVM2_m LVM2 fcKmkV-QD9d-gfGU-kyaG-S7l6-iNAM-IBLmfF ├─system-swap │ swap 1 e2a1b8f2-6926-47ff-bca1-177fe34f2b3c [SWAP] └─system-root btrfs 92760c3c-52e1-4cbb-9c64-2edc6f61cca6 136.5G 70% /var /usr/local /tmp /root /srv /opt /home /boot/grub2/x86_64-efi /boot/grub2/i386-pc /.snapshots
(In reply to Andrei Borzenkov from comment #4 and #12 and Neil Rickert from #9) The root cause is something like this: 1) New variable might be installed before by someone by mokutil in spec file "mokutil --set-sbat-policy latest" which will generate newest variable: sbat,1,2022111500 shim,2 grub,3 2) Old shim or old grub is installed again: If the generation# of shim or grub is smaller than new variable, shim will be blocked and show "Verification failed: Security Policy Violation" 3) Please also check the generation# of opensuse/shim.efi, boot/bootx64.efi and opensuse/grub.efi > objdump -j .sbat -s shim.efi > objdump -j .sbat -s bootx64.efi > objdump -j .sbat -s grub.efi
The problem for me, is that I have both Leap 15.4 and Tumbleweed installed. If Leap 15.4 is controlling the booting, then all is fine. However, if a Tumbleweed update includes a bootloader update, that will switch so that Tumbleweed takes over managing the booting. And that won't work until the shim in Tumbleweed is brought up to the same SBAT level. Realistically, we need a shim update in Tumbleweed. And we really should have an updated install iso for Leap 15.4 that uses the new shim. I cannot boot the install iso currently available unless I disable secure-boot.
(In reply to Neil Rickert from comment #22) > The problem for me, is that I have both Leap 15.4 and Tumbleweed installed. > > If Leap 15.4 is controlling the booting, then all is fine. However, if a > Tumbleweed update includes a bootloader update, that will switch so that > Tumbleweed takes over managing the booting. And that won't work until the > shim in Tumbleweed is brought up to the same SBAT level. > > Realistically, we need a shim update in Tumbleweed. And we really should > have an updated install iso for Leap 15.4 that uses the new shim. I cannot > boot the install iso currently available unless I disable secure-boot. You can use https://download.opensuse.org/distribution/leap/15.4/appliances/iso/openSUSE-Leap-15.4-CR-DVD-x86_64-Media.iso, that's also linked as "Updated offline image" on get.o.o. (In reply to Tseng from comment #21) > (In reply to Andrei Borzenkov from comment #4 and #12 and Neil Rickert from > #9) > > The root cause is something like this: > 1) New variable might be installed before by someone by mokutil in spec file > "mokutil --set-sbat-policy latest" > which will generate newest variable: > sbat,1,2022111500 > shim,2 > grub,3 Urgh, shim actually does that. Not good. My expectation was that shim only does that itself on boot. Anything else results in a soft brick of the device. > 2) Old shim or old grub is installed again: Or the shim/grub update does not end up being used because something is not configured correctly or the system is intentionally configured not to write nvram variables, e.g. because a different OS is responsible for shim. > If the generation# of shim or grub is smaller than new variable, shim > will > be blocked and show "Verification failed: Security Policy Violation" > > 3) Please also check the generation# of opensuse/shim.efi, boot/bootx64.efi > and > opensuse/grub.efi > > objdump -j .sbat -s shim.efi > > objdump -j .sbat -s bootx64.efi > > objdump -j .sbat -s grub.efi
(In reply to Fabian Vogt from comment #23) > > 1) New variable might be installed before by someone by mokutil in spec file > > "mokutil --set-sbat-policy latest" > > which will generate newest variable: > > sbat,1,2022111500 > > shim,2 > > grub,3 > > Urgh, shim actually does that. Not good. My expectation was that shim only > does that itself on boot. The SbatPolicy *is* set by shim on boot; mokutil just tells shim which of the two compiled in values it has to apply. So new shim must boot at least once for this to have any effect. > > Or the shim/grub update does not end up being used because something is not > configured correctly There are known systems which simply ignore EFI boot configuration and always try to boot Windows or use \EFI\Boot. On such systems the only solution is to manually copy Linux bootloader into other place(s). These places will not be updated and you get this error - *IF* new shim manages to execute, which arguably should not be possible on such system. We have this bug report and forum report from non-multiboot systems but lack factual information in both cases. > or the system is intentionally configured not to write > nvram variables, e.g. because a different OS is responsible for shim. > Arguably multiboot case is user error. Allowing each installed system to overwrite bootloader will likely have bad effects even without this issue. Unfortunately, as long as we rely on os-prober to boot different Linux instances we must generate bootloader configuration for each Linux on kernel update. There is no way to tell (open)SUSE to use --no-nvram (and it has to be supported by each installed distribution anyway).
(In reply to Andrei Borzenkov from comment #24) > (In reply to Fabian Vogt from comment #23) > > > 1) New variable might be installed before by someone by mokutil in spec file > > > "mokutil --set-sbat-policy latest" > > > which will generate newest variable: > > > sbat,1,2022111500 > > > shim,2 > > > grub,3 > > > > Urgh, shim actually does that. Not good. My expectation was that shim only > > does that itself on boot. > > The SbatPolicy *is* set by shim on boot; mokutil just tells shim which of > the two compiled in values it has to apply. So new shim must boot at least > once for this to have any effect. Ok, so it's not possible that old shim somehow reacts to this mokutil call by writing an "invalid" sbat policy? > > Or the shim/grub update does not end up being used because something is not > > configured correctly > > There are known systems which simply ignore EFI boot configuration and > always try to boot Windows or use \EFI\Boot. On such systems the only > solution is to manually copy Linux bootloader into other place(s). These > places will not be updated and you get this error - *IF* new shim manages to > execute, which arguably should not be possible on such system. We have this > bug report and forum report from non-multiboot systems but lack factual > information in both cases. Yep... > > or the system is intentionally configured not to write > > nvram variables, e.g. because a different OS is responsible for shim. > > Arguably multiboot case is user error. Allowing each installed system to > overwrite bootloader will likely have bad effects even without this issue. > > Unfortunately, as long as we rely on os-prober to boot different Linux > instances we must generate bootloader configuration for each Linux on kernel > update. There is no way to tell (open)SUSE to use --no-nvram (and it has to > be supported by each installed distribution anyway).
(In reply to Fabian Vogt from comment #25) > > > > The SbatPolicy *is* set by shim on boot; Sorry, it is SbatLevel of course. SbatPolicy is set by mokutil to "latest" etc. > mokutil just tells shim which of > > the two compiled in values it has to apply. So new shim must boot at least > > once for this to have any effect. > > Ok, so it's not possible that old shim somehow reacts to this mokutil call by > writing an "invalid" sbat policy? > If the old shim supports SbatPolicy, it will set SbatLevel to the compiled-in "latest" policy. The shim 15.4 in Leap did not support SbatPolicy and would not change SbatLevel because it is newer.
Replying to Fabian Vogt at comment #23 >You can use https://download.opensuse.org/distribution/leap/15.4/appliances/iso/openSUSE-Leap-15.4-CR-DVD-x86_64-Media.iso, that's also linked as "Updated offline image" on get.o.o. I just downloaded that for testing. Unfortunately, it is still using the older shim so won't boot with secure-boot enabled. Using "--no-nvram" does not help here, if the multiboot systems are all opensuse. Any booting update will overwrite the files in "/boot/efi/EFI/opensuse" and the most recently update will control the booting, even without an NVRAM update. I'll note that I am able to cope with this. But less experienced openSUSE users are likely to run into problems. Fortunately, the recent iso for 15.5Beta is using the newer shim, and I can use the rescue system on that if needed.
(In reply to Neil Rickert from comment #27) > Replying to Fabian Vogt at comment #23 > > >You can use https://download.opensuse.org/distribution/leap/15.4/appliances/iso/openSUSE-Leap-15.4-CR-DVD-x86_64-Media.iso, that's also linked as "Updated offline image" on get.o.o. > > I just downloaded that for testing. Unfortunately, it is still using the > older shim so won't boot with secure-boot enabled. Fixed. The new shim RPM was on the DVD, but installation-images had to be rebuilt as well to get it into the ESP.
We've been hit by this, too, with (possibly) a twist and I'm trying to wrap my head around what's written in this ticket: We're bare-metal installing systems via SUSE Manager, various OS releases of SLED and openSUSE Leap. No Tumbleweed involved. When PXE-booting the clients, shim.efi is pulled from the SUSE Manager system (based on code level 15SP4). If we install Leap 15.4, then newer code may be installed on the clients, which seems to be updating SbatLevel on the client: later reboots via PXE to re-install the system then fail, because the (older) shim from SUSE Manager will not validate. Current situation for our systems is that booting from disk succeeds, but booting via network fails (if SecureBoot is activated). If the version mismatch is the actual cause, then we're between a rock and a hard place: - (manually) updating shim on SUSE Manager system will allow to re-install latest Leap 15.4 systems, but will break installs of older systems (i.e. SLED/SLES 15SP3 will no longer be able to boot from disk, because of the older shim installed locally) - keeping the original shim on SUSE Manager will allow to install and local-boot any OS level, but updating Leap 15.4 to the latest level will break network-based re-installs, because shim.efi used by PXE is too old. Or did I get some of the comments wrong and it's all different from what I described above?
no i thiunk this is about right. i learned that SUSE Manager uses tftpboot images from SLE, so we need to also update those. I set this in motion.
(In reply to Marcus Meissner from comment #30) > no i thiunk this is about right. > > i learned that SUSE Manager uses tftpboot images from SLE, so we need to > also update those. I set this in motion. Yes it does - it's taken from the according package for the OS release that SUSE Manager is based on (SLE 15 SP4 for the current SUSE Manager version). But please keep in mind that if we're using a current shim ("SbatVersion 3") during PXE phase, then the clients' SecureBoot setup will likely have the SbatVersion updated during that boot. If we're then installing an older version of SLED or SLES to the client's disk, that OS might come with an older version of shim.efi and local boot might fail. IOW, you'd need to update shim.efi (or whatever component is used during *local* SecureBoot mode) for any installed OS as well, else the systems will fail to boot from local media. For this type of scenario, you have to either update none or all supported OS versions to the new shim?
Please let me simplify the shim usage (or saying simplify the bug): - shim doesn't encourage mix-environment or multiboot. - New shim will revoke old one when you install a mix-environment. - If you really need a mix-environment, please disable secure boot or reset(delete) SbatLevel variables to 'ORIGINAL' defined in upstream shim/include/sbat_var_defs.h by using mokutil - Comment#4, comment#12 and comment#22 have shown this bug is nothing to do the bug title. Also,it is nothing to do with *Urgh* - I'm the bug owner. I'd like to change the bug title to "How to correctly using shim to upgrade OS ?"
The SBAT function is for block old shim or old grub2 because they have vulnerability. So, old shim be blocked by SBAT is a security mechanism. Setting the SBAT policy to latest is also in the mechanism. If anyone want to use new shim and old shim in one machine. User should aware that the old shim has vulnerability. User can just disable secure boot if you still want to do that. Or clear SBAT policy. The new 15.7 shim for openSUSE Tumbleweed be sent to shim-review project for reviewing. The latest round be rejected, we will send another round with NX support for reviewing. If anyone interested about it. Welcome join: https://github.com/rhboot/shim-review/issues/329 We can launch another bug to track the status of Tumbleweed shim. On the other hand, for those issues about installation or PXE. Please file other bug to trace it. Maybe we need more changes in installation or more documentation.
I changed the subject to " Secure boot violation when install Leap shim and Tumbleweed shim in one machine" to indicate the status. And set this issue to WONTFIX. Feel free to reopen it if anyone still has concern.
(In reply to Joey Lee from comment #33) > If anyone want to use new shim and old shim in one machine. User should > aware that the old shim has vulnerability. User can just disable secure boot I need to test things with Secureboot. So this is no option for me. > if you still want to do that. Or clear SBAT policy. How? After reading the comments here, for me it loooks like this simply does not work. As usual the ugliest workaround would be more than good enough for me. ;-)
(In reply to Stefan Dirsch from comment #35) > > How? mokutil --set-sbat-policy previous This will work until "previous" policy will not become too new.
(In reply to Andrei Borzenkov from comment #36) > (In reply to Stefan Dirsch from comment #35) > > > > How? > > mokutil --set-sbat-policy previous > > This will work until "previous" policy will not become too new. Thanks. Unfortunately this didn't help. Seems the "previous" policy was already too new. :-( So after running the command I had the same setting as before, i.e. # cat /syst/firmware/efi/efivars/SbatLevel* sbat,1,2022111500 shim,2 grub,3
(In reply to Stefan Dirsch from comment #37) > (In reply to Andrei Borzenkov from comment #36) > > (In reply to Stefan Dirsch from comment #35) > > > > > > How? > > > > mokutil --set-sbat-policy previous > > > > This will work until "previous" policy will not become too new. > > Thanks. Unfortunately this didn't help. Sorry, it will not downgrade so you need to first disable secure boot, delete current and then set "previous" policy and then enable secure boot. And you need to disable Secure Boot on firmware level, "mokutil --disable-validation" is not enough. bor@localhost:~> rpm -q shim shim-15.7-150300.4.11.1.x86_64 bor@localhost:~> mokutil --list-sbat-revocations sbat,1,2022111500 shim,2 grub,3 bor@localhost:~> sudo reboot ... Enter setup, disable Secure Boot ... bor@localhost:~> dd status=none bs=1 skip=4 if=/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | hexdump -C 00000000 00 |.| 00000001 bor@localhost:~> dd status=none bs=1 skip=4 if=/sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23 | hexdump -C dd: failed to open '/sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23': No such file or directory bor@localhost:~> mokutil --list-sbat-revocations sbat,1,2022111500 shim,2 grub,3 bor@localhost:~> sudo mokutil --set-sbat-policy delete [sudo] password for root: bor@localhost:~> sudo reboot ... bor@localhost:~> mokutil --list-sbat-revocations sbat,1,2021030218 bor@localhost:~> dd status=none bs=1 skip=4 if=/sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23 | hexdump -C dd: failed to open '/sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23': No such file or directory bor@localhost:~> sudo mokutil --set-sbat-policy previous [sudo] password for root: bor@localhost:~> sudo reboot ... Enter Setup, enable Secure Boot ... or@localhost:~> mokutil --list-sbat-revocations sbat,1,2022052400 grub,2 bor@localhost:~> dd status=none bs=1 skip=4 if=/sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23 | hexdump -C 00000000 02 |.| 00000001 bor@localhost:~> dd status=none bs=1 skip=4 if=/sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | hexdump -C 00000000 01 |.| 00000001 bor@localhost:~>
Thanks @Andrei ! Indeed this worked for me to revive the machine for TW secureboot testing! I assume things will get broken again with next installation of Leap 15.4/15.5 though. So I will need to do this again in the future ...
(In reply to Stefan Dirsch from comment #39) > I assume things will get broken again with next > installation of Leap 15.4/15.5 though. shim postinstall script does nothing if SbatPolicy is present. So unless it is changed (or installer does something on its own) it should remain. For how long we do not know (probably until the next round of CVE fixes in shim/grub2).
Oh. That sounds great! Thanks for letting me know.
Here's my experience with this: Once the latest sbat policy has been set, there is no way unset it other that to clear it. To clear: Disable secure-boot (in BIOS settings) mokutil --set-sbat-policy delete reboot The reboot (with the newest shim) clears the policy. You can then enable secure-boot again. However, any "shim" update is likely to revert back to the latest policy. For a recent "shim" update on 15.4: I installed the update. I then ran: mokutil --set-sbat-policy previous I ran that command before the reboot, and that seems to have saved me from needing to clear once again. I'll note that on a test system (in a VM), when I did not run that "mokutil" command after the "shim" update, then I found I was back to the latest policy and the problems that causes. So, for now, after any "shim" update on 15.4 or 15.5, I plan to run that "mokutil" command to set the previous policy. And I have to do that before I reboot.
(In reply to Neil Rickert from comment #42) > Here's my experience with this: > > Once the latest sbat policy has been set, there is no way unset it other > that to clear it. > > To clear: > > Disable secure-boot (in BIOS settings) > mokutil --set-sbat-policy delete > reboot > > The reboot (with the newest shim) clears the policy. You can then enable > secure-boot again. > > However, any "shim" update is likely to revert back to the latest policy. > > For a recent "shim" update on 15.4: > > I installed the update. > > I then ran: > > mokutil --set-sbat-policy previous > > I ran that command before the reboot, and that seems to have saved me from > needing to clear once again. > > I'll note that on a test system (in a VM), when I did not run that "mokutil" > command after the "shim" update, then I found I was back to the latest > policy and the problems that causes. So, for now, after any "shim" update > on 15.4 or 15.5, I plan to run that "mokutil" command to set the previous > policy. And I have to do that before I reboot. The status form of SBAT policy for reference: Secure Boot OFF +------------------------+----------+---------+ | old state| delete | previous | latest | | new state | | | | +--------------+---------+----------+---------+ | delete | N/A | YES | YES | +--------------+---------+----------+---------+ | previous | YES | N/A | NO (1)| +--------------+---------+--------------------+ | latest | YES | YES | N/A | +--------------+---------+--------------------+ (1) blocked by datestamp Secure Boot ON +------------------------+----------+---------+ | old state| delete | previous | latest | | new state | | | | +--------------+---------+----------+---------+ | delete | N/A | NO (2) | NO (2)| +--------------+---------+----------+---------+ | previous | YES | N/A | NO (1)| +--------------+---------+--------------------+ | latest | YES | YES | N/A | +--------------+---------+--------------------+ (1) blocked by datestamp (2) blocked by secure boot
Created attachment 866913 [details] SBAT-policy-transitions-chart.png (In reply to Joey Lee from comment #43) > > The status form of SBAT policy for reference: > > Secure Boot OFF > +------------------------+----------+---------+ > | old state| delete | previous | latest | > | new state | | | | > +--------------+---------+----------+---------+ > | delete | N/A | YES | YES | > +--------------+---------+----------+---------+ > | previous | YES | N/A | NO (1)| > +--------------+---------+--------------------+ > | latest | YES | YES | N/A | > +--------------+---------+--------------------+ > (1) blocked by datestamp > > > Secure Boot ON > +------------------------+----------+---------+ > | old state| delete | previous | latest | > | new state | | | | > +--------------+---------+----------+---------+ > | delete | N/A | NO (2) | NO (2)| > +--------------+---------+----------+---------+ > | previous | YES | N/A | NO (1)| > +--------------+---------+--------------------+ > | latest | YES | YES | N/A | > +--------------+---------+--------------------+ > (1) blocked by datestamp > (2) blocked by secure boot SBAT policy transitions chart for reference
Small comment: Would be nice to have "mokutil" available in the rescue image.
(In reply to Peter Stark from comment #45) > Small comment: Would be nice to have "mokutil" available in the rescue image. I added it to the rescue live image: https://build.opensuse.org/request/show/1094667 To get it added to the "rescue" option of the installation DVD as well that's something for snwint.
Here you go: https://github.com/openSUSE/installation-images/pull/649
(In reply to Steffen Winterfeldt from comment #47) > https://github.com/openSUSE/installation-images/pull/649 kudos!
just a quick update from my side: I have updated to openSUSE leap 15.5 yesterday, SecureBoot is enabled now again and I do not have any issues anymore when starting the laptop
(In reply to Julia Faltenbacher from comment #49) > just a quick update from my side: > I have updated to openSUSE leap 15.5 yesterday, SecureBoot is enabled now > again and I do not have any issues anymore when starting the laptop Not working on Tumbleweed.
*** Bug 1213408 has been marked as a duplicate of this bug. ***
(In reply to Joey Lee from comment #44) > Created attachment 866913 [details] > SBAT-policy-transitions-chart.png > > (In reply to Joey Lee from comment #43) > > > > The status form of SBAT policy for reference: > > > > Secure Boot OFF > > +------------------------+----------+---------+ > > | old state| delete | previous | latest | > > | new state | | | | > > +--------------+---------+----------+---------+ > > | delete | N/A | YES | YES | > > +--------------+---------+----------+---------+ > > | previous | YES | N/A | NO (1)| > > +--------------+---------+--------------------+ > > | latest | YES | YES | N/A | > > +--------------+---------+--------------------+ > > (1) blocked by datestamp > > > > > > Secure Boot ON > > +------------------------+----------+---------+ > > | old state| delete | previous | latest | > > | new state | | | | > > +--------------+---------+----------+---------+ > > | delete | N/A | NO (2) | NO (2)| > > +--------------+---------+----------+---------+ > > | previous | YES | N/A | NO (1)| > > +--------------+---------+--------------------+ > > | latest | YES | YES | N/A | > > +--------------+---------+--------------------+ > > (1) blocked by datestamp > > (2) blocked by secure boot > > SBAT policy transitions chart for reference Add a simple step by step process here to reset SbatLevelRT efi variable to original string (aka. delete) for booting shim 15.4 in Leap 15.4 image after user installed shim 15.7 in Leap 15.5 image: Situation: You have installed Leap 15.5 which means the shim 15.7 is your default first-stage bootloader now. Then you want to boot the shim 15.4 in Leap 15.4 iso image. But the shim 15.4 be blocked by SBAT self-block mechanism. You saw the following messages be shown on screen: Verifying shim SBAT data failed: Security Policy Violation Something has gone serously wrong: SBAT self-check failed: Security Policy Violation Note: The above violation message is exposed by shim 15.4's SBAT self-block mechanism. This mechanism is the only SBAT function be supported by old shim 15.4 in Leap 15.4 iso image. Step by step for resetting SBAT efi variable (aka. SbatLevelRT): - Reboot to firmware UI to disable secure boot - Boot to Leap 15.5, run mokutil command in terminal: # Check secure boot state: localhost:~ # mokutil --sb SecureBoot disabled # Check current SBAT string in SbatLevelRT variable. Default is "latest" mode as following: localhost:~ # mokutil --list-sbat-revocations sbat,1,2022111500 shim,2 grub,3 # Run mokutil to set SBAT policy to "delete" localhost:~ # mokutil --set-sbat-policy delete # You can hexdump SbatPolicy efi variable to confirm, the command 3 be written to SbatPolicy variable localhost:~ # hexdump /sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23 0000000 0007 0000 0003 0000005 - Reboot to Leap 15.5, which means booting to shim 15.7. The shim 15.7 will take the delete mission and reset SbatLevelRT variable to "original" mode. Note: Please do NOT reboot to Leap 15.4 (which means you boot to shim 15.4). The old shim 15.4 does NOT support "--set-sbat-policy" command for resetting SbatLevelRT. The mokuil delete command will be ignored by shim 15.4. - Now you still boot to Leap 15.5, run mokutil command in terminal to confirm that the SBAT string be changed to "original" mode (aka. delete): localhost:~ # mokutil --list-sbat-revocations sbat,1,2021030218 AS the above result, the original string only has a SBAT version, without shim or grub2 SBAT entries. It means that shim SBAT will NOT block anything. - Now you can reboot to firmware UI to enable secure boot. - Then boot to old shim 15.4 with Leap 15.4. The SBAT self-block mechanism will not stop shim 15.4 itself now.
(In reply to Joey Lee from comment #52) > (In reply to Joey Lee from comment #44) > > Created attachment 866913 [details] > > SBAT-policy-transitions-chart.png > > > > (In reply to Joey Lee from comment #43) > > > > > > The status form of SBAT policy for reference: > > > > > > Secure Boot OFF > > > +------------------------+----------+---------+ > > > | old state| delete | previous | latest | > > > | new state | | | | > > > +--------------+---------+----------+---------+ > > > | delete | N/A | YES | YES | > > > +--------------+---------+----------+---------+ > > > | previous | YES | N/A | NO (1)| > > > +--------------+---------+--------------------+ > > > | latest | YES | YES | N/A | > > > +--------------+---------+--------------------+ > > > (1) blocked by datestamp > > > > > > > > > Secure Boot ON > > > +------------------------+----------+---------+ > > > | old state| delete | previous | latest | > > > | new state | | | | > > > +--------------+---------+----------+---------+ > > > | delete | N/A | NO (2) | NO (2)| > > > +--------------+---------+----------+---------+ > > > | previous | YES | N/A | NO (1)| > > > +--------------+---------+--------------------+ > > > | latest | YES | YES | N/A | > > > +--------------+---------+--------------------+ > > > (1) blocked by datestamp > > > (2) blocked by secure boot > > > > SBAT policy transitions chart for reference > > Add a simple step by step process here to reset SbatLevelRT efi variable to > original string (aka. delete) for booting shim 15.4 in Leap 15.4 image after > user installed shim 15.7 in Leap 15.5 image: > > Situation: > > You have installed Leap 15.5 which means the shim 15.7 is your default > first-stage bootloader now. Then you want to boot the shim 15.4 in Leap 15.4 > iso image. But the shim 15.4 be blocked by SBAT self-block mechanism. You > saw the following messages be shown on screen: > > Verifying shim SBAT data failed: Security Policy Violation > Something has gone serously wrong: SBAT self-check failed: Security Policy > Violation > > Note: > The above violation message is exposed by shim 15.4's SBAT self-block > mechanism. This mechanism is the only SBAT function be supported by old shim > 15.4 in Leap 15.4 iso image. > > Step by step for resetting SBAT efi variable (aka. SbatLevelRT): > > - Reboot to firmware UI to disable secure boot > - Boot to Leap 15.5, run mokutil command in terminal: > > # Check secure boot state: > localhost:~ # mokutil --sb > SecureBoot disabled > > # Check current SBAT string in SbatLevelRT variable. Default is "latest" > mode as following: > localhost:~ # mokutil --list-sbat-revocations > sbat,1,2022111500 > shim,2 > grub,3 > > # Run mokutil to set SBAT policy to "delete" > localhost:~ # mokutil --set-sbat-policy delete > > # You can hexdump SbatPolicy efi variable to confirm, the command 3 be > written to SbatPolicy variable > localhost:~ # hexdump > /sys/firmware/efi/efivars/SbatPolicy-605dab50-e046-4300-abb6-3dd810dd8b23 > 0000000 0007 0000 0003 > 0000005 > > - Reboot to Leap 15.5, which means booting to shim 15.7. The shim 15.7 will > take the delete mission and reset SbatLevelRT variable to "original" mode. > > Note: > Please do NOT reboot to Leap 15.4 (which means you boot to shim 15.4). The > old shim 15.4 does NOT support "--set-sbat-policy" command for resetting > SbatLevelRT. The mokuil delete command will be ignored by shim 15.4. > > - Now you still boot to Leap 15.5, run mokutil command in terminal to > confirm that the SBAT string be changed to "original" mode (aka. delete): > > localhost:~ # mokutil --list-sbat-revocations > sbat,1,2021030218 > > AS the above result, the original string only has a SBAT version, without > shim or grub2 SBAT entries. It means that shim SBAT will NOT block anything. > > - Now you can reboot to firmware UI to enable secure boot. > - Then boot to old shim 15.4 with Leap 15.4. The SBAT self-block mechanism > will not stop shim 15.4 itself now. I have updated openSUSE UEFI wiki page to add reset SBAT section: https://en.opensuse.org/openSUSE:UEFI#Reset_SBAT_string_for_booting_to_old_shim_in_old_Leap_image
Replying to Joey Lee c#52 >Add a simple step by step process here to reset SbatLevelRT efi variable to original string Thanks. I've actually been doing that, based on the suggestion in c#4 and it works well and also allows booting Tumbleweed.
This is an autogenerated message for OBS integration: This bug (1209985) was mentioned in https://build.opensuse.org/request/show/1123864 15.5:Images / livecd-openSUSE
*** Bug 1227415 has been marked as a duplicate of this bug. ***