The latest Microsoft update marks multi-boot setups as "violating security policies."

[haobinnan]

https://support.microsoft.com/en-us/topic/august-13-2024-kb5041571-os-build-26100-1457-d218c08d-8de2-4f9a-8fe1-a2c2fd83ca9a

https://forums.linuxmint.com/viewtopic.php?t=427297

How should we respond to this?

[jsetje]

These revocations should not be revoking any of the most up-to-date binaries. Systems that run into this can likely be recovered by disabling secure boot and clearing the SbatLevel via "sudo mokutil --set-sbat-policy delete" and then updating to the latest packages before booting Windows again.

Windows is supposed to check for signs of an installed OS that could be revoked by SBAT and, if it finds one, leave managing SBAT based revocations up to that OS. Based on the public reports there are some cases that are not being caught, impacting some boot devices more than others. This is being investigated.

This check can not find an OS that's booted at a later point from removable (USB) media. While in general such removable media should be updated regularly, that may not be common practice in all places yet. However we should not assume that any Windows PC will be able to boot arbitrarily old media without system owner (UEFI Setup access) intervention.

Client systems that ship with Windows pre-installed may also have SBAT revocations applied. The recommended approach is to always provision a client device using the latest update release for the Linux distro being installed. However if there is a need to install an older update release on a system that is in a state where it rejects it, the following steps can be used to clear these revocations:

1. Boot the latest media with Secure Boot enabled to confirm that that media has properly signed binaries and is trusted.
2. Disable Secure Boot
3. Boot the same, latest, media that was just validated previously to have shim 15.8 clear SbatLevel
4. Re-enable Secure Boot
5. Boot and install from the older media

Systems that routinely run both Windows and older Linux release where the Linux root is not visible while Windows is running can use a registry setting to prevent Windows from applying SBAT based revocations.

[jsetje]

15.7 shims require "sudo mokutil --set-sbat-policy delete" when Secure Boot is disabled to clear SbatLevel.
15.8 (and newer) shims will automatically clear SbatLevel when Secure Boot is disabled.

The current revocations are revoking 15.7 shims, so an installed OS being blocked will require the mokutil command to clear SbatLevel once Secure Boot is disabled.

[haobinnan]

Thank you for your response. I found that 15.8 is normal, and only shims less than 15.8 are abnormal.

@jsetje

[julian-klode]

Just reopening this for visibility

[jsetje]

I will keep updating my top comment with the most concise information that I have available. Please feel free to share that with anyone that needs it.

[karniemi]

The title can now be enhanced: also latest linux-distro updates have the very same effect. And it's not only caused by updating a linux system: just booting a recent linux live-CDs updates the sbat policies, effectively 1) making a Secure booted system unbootable 2) making other/older live-CDs unbootable 2) making any system backups unbootable. One would never expect such catastrophic effect from booting a live-cd.