Microsoft extends workaround for Windows SBAT update

The update for Windows 10 and 11 on August 13 not only paralyzed various live Linux systems on USB sticks. Because the detection of Linux systems installed in parallel included in the update failed in some scenarios, some Linux systems that had already been installed were also paralyzed. Microsoft has now published a second workaround that should allow previously blocked installations to boot again. However, this does not go far enough, it only removes the locks completely and thus overrides Secure Boot. An additional step is required to restore the status prior to the update.

With the update described in KB5041571 (Windows 11) and KB5041580 (Windows 10), Microsoft has retrofitted the Secure Boot Advanced Targeting (SBAT) developed by the open source community to Windows PCs. This should block older and insecure boot loaders. Since Linux bootloaders already support SBAT, Microsoft is using the new technology to save valuable space in the DBX blacklist of the UEFI BIOS, which was used exclusively for previous bootloader blocking.

According to the plan, this should only happen on computers without a parallel Linux installation so that the Windows update does not interfere with the Linux installation. Instead, vulnerable bootloaders should be locked in the course of regular distribution updates and not by Windows updates. The idea is good in principle, because without installing SBAT, Windows-only PCs would continue to start insecure Linux boot loaders from USB sticks, for example, so that an attacker could break through Secure Boot. The only alternative would be to put the Linux boot loaders that are actually to be blocked by SBAT back on the DBX block list and thus further inflate it.

Prevent SBAT update

Due to the unreliable Linux detection, however, the Windows update overwrote the SBAT lists of the Linux systems on some computers and thus blocked them. Microsoft's first workaround to prevent this scenario starts with the installation of the cumulative update from August 13. This requires the computer to be restarted at the end. If the restart has not yet taken place, you can use the following registry entry to prevent SBAT from being installed:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD

Do not restart to complete the update until the entry has been made.

Reverse role

Microsoft has now added a second workaround in the Windows Release Health Center for cases where the Windows update has already been installed at an earlier point in time. If SBAT is already preventing Linux from booting, you must first disable Secure Boot in the UEFI BIOS. However, not before you have written down your BitLocker recovery key, printed it out or backed it up on a USB stick: The drive encryption sometimes reacts sensitively to changes in Secure Boot and then requires you to enter the key so that you can restart your Windows.

Without Secure Boot, you can now restart your installed Linux from the hard disk. Open a terminal and first check whether the SBAT lock list from Microsoft has actually been imported:

mokutil --list-sbat-revocations

Pay attention to the timestamp, which is 2024010900 for Microsoft's SBAT update. To delete the blacklist again, use the command mentioned in Microsoft's second workaround:

sudo mokutil --set-sbat-policy delete

It is now important to restart the computer for the change to take effect – again with Secure Boot deactivated. Back in the terminal under Linux, check whether the list has been successfully deleted:

mokutil --list-sbat-revocations

The timestamp is now a different, older one than before, and there are no more entries for Shim and Grub. If it did not work the first time, try deleting the SBAT list again.

Close the gap

However, this completely disables SBAT and subsequently also Secure Boot and your computer will boot all boot loaders that were previously blocked by your Linux distribution via updates to the SBAT block list. If you were to activate Secure Boot now, only some of the locks would be effective. To restore the status before the Windows update, use the following command to restore the SBAT blacklist of your Linux distribution:

sudo mokutil --set-sbat-policy latest

Now a restart is due again after you have displayed the currently valid SBAT lock list:

mokutil --list-sbat-revocations

If you now find at least one entry each for Shim and Grub in addition to the line with the timestamp, the update was successful, and you can reactivate Secure Boot in the UEFI BIOS – if you still want to do so. To prevent Windows from interfering with SBAT in the future, you must set the following registry key under Windows:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT /v OptOut /d 1 /t REG_DWORD

This leaves Linux to update the SBAT blacklists and Windows takes care of any vulnerable Windows bootloaders.

(mid)