[German]Users who use Windows and Linux via Secure Boot on computers are likely to have a problem since August 13, 2024. Microsoft has changed something in the boot process with the August 2024 Patchday and switched boot entries from DBX to Secure Boot Advanced Targeting (SBAT). As a result, Linux installations on the affected systems no longer start in Secure Boot mode. Imho, this means switching off Secure Boot mode and waiting for updated Linux distributions.
Advertising
SBAT shipped with August 2024 Updates
I only noticed it in passing, Microsoft has introduced Secure Boot Advanced Targeting (SBAT) for all supported Windows versions in the August 2024 updates for Windows. The relevant support articles state this:
[Secure Boot Advanced Targeting (SBAT) and Linux Extensible Firmware Interface (EFI)] This update applies SBAT to systems that run Windows. This stops vulnerable Linux EFI (Shim bootloaders) from running. This SBAT update will not apply to systems that dual-boot Windows and Linux. After the SBAT update is applied, older Linux ISO images might not boot. If this occurs, work with your Linux vendor to get an updated ISO image.
These updates introduce Secure Boot Advanced Targeting (SBAT) on Windows systems. The aim is to prevent vulnerable Linux EFI (shim boot loaders) from being executed. Microsoft writes: "This SBAT update does not apply to systems that run Windows and Linux in dual-boot mode" and at the same time warns: "After applying the SBAT update, older Linux ISO images may no longer boot. In this case, contact your Linux vendor to obtain an updated ISO image."
Reader reports about boot issues
In this German comment, FFred asked for information about the consequences of the introduction of Secure Boot Advanced Targeting (SBAT), and German reader Bolko referred to a post at German magazine heise where issues with booting Linux systems were discussed. German blog reader Paul responded in this comment and reported also boot problems.
I noticed something like this today AFTER the August update KB5041580 (W10) with my Ventoy USB stick (UEFI, version 1.0.98), which worked BEFORE this update n0ch with secure boot enabled.
When trying to boot from the USB stick, an error message appeared, which was the first time I had seen this:
———————–
Verifying shim SBAT data failed: Security Policy Violation
Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
———————–
The message appeared for a good 5 seconds on a black background and then the computer switched off. After switching off Secure Boot, it worked again.The Windows update must have wiped the security key from the BIOS, I suspect.
German blog reader Peter posted this comment on August 18, 2024 and writes that SBAT also runs in dual boot mode after the August 2024 update – in contrast to the Microsoft statement above. He also received the message "Verifying shim SBAT data failed: Security Policy Violation" and the computer shuts down. The only solution is to disable Secure Boot for the machine.
Another report
I already had a blog post on the subject on my "radar" when I received an e-mail from blog reader Tibor, who received after installing a Windows 11 update the error message:
Advertising
Verifying shim SBAT data failed: Security Policy Validation
The computer in question shut down after a few seconds. He runs Linux Mint 20.3 and Windows 11 in dual boot on his computer. When he researched the topic, he came across the reason outlined above and wrote:
Researching this term left me completely stunned: Microsoft tampered with my UEFI BIOS with Secure Boot
and TPM, so that I could now only start Windows 11 with Secure Boot enabled. Both worked without Secure Boot!
He found after a long search a workaround for him, but told me later, the the fix failed after a day.
The reader also wrote that Microsoft had already made announcements about this. However, no-one was aware that this would have such a severe impact. The reader also noted that some older PCs with 3rd generation Intel CPUs do not even display the above error message. Instead, the device goes into a boot loop. He believes that the Linux community is partly to blame, as they repeatedly advise disabling Secure Boot.
Nightmares come true
If I remember correctly, developers from the Linux community warned more than 14 years ago that Microsoft's Secure Boot was the kill switch to shut down Linux on Windows computers. From the Windows corner, it was always said that Linux developers only had to provide a valid Secure Boot loader. As a result, such loaders were developed for Linux so that systems with Secure Boot could boot both Windows and Linux.
Now such a scenario has come true – heise has described it here. Until now, the signatures required for booting were stored in the DBX database of the BIOS/UEFI. German site heise writes that this database is too small for many signature entries in some BIOS systems. With the August 2024 updates, Microsoft has now retrofitted the Secure Boot Advanced Targeting (SBAT) developed by the open source community – an explanation of the UEFI shim boot loader can be found here.
With the August 2024 updates, Microsoft has started to lock the keys for the boot loaders stored in the UEFI DBX database. Now it is the Linux boot loaders Shim and Grub that refuse to boot the system because the integrity of the secure boot is no longer guaranteed, explains heise. Hacker News has also anotherexplanation here. It is currently unclear which Linux distributions are affected. At the moment, however, the solution is probably to "switch off Secure Boot and wait for an updated Linux distribution" to solve the problem.
All problems that the user does not need. And it is doubtful whether the systems will really become more secure as a result of Secure Boot and the above-mentioned loopholes.
Similar articles:
Microsoft Security Update Summary (August 13, 2024)
Patchday: Windows 10/Server Updates (August 13, 2024)
Patchday: Windows 11/Server 2022-Updates (August 13, 2024)
Windows Server 2012 / R2 and Windows 7 (August 13, 2024)
Advertising
