Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
haobinnan opened this issue Aug 16, 2024 · 5 comments
Labels

Comments

@haobinnan
Copy link

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

1

How should we respond to this?

@jsetje
Copy link
Collaborator

jsetje commented Aug 21, 2024

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
Copy link
Collaborator

jsetje commented Aug 21, 2024

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
Copy link
Author

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

@jsetje

@julian-klode
Copy link
Collaborator

Just reopening this for visibility

@jsetje
Copy link
Collaborator

jsetje commented Aug 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants