Microsoft is known for their signature, “my way or the highway” approach when it comes to their offerings, with the Windows operating system being the most prominent one among those.
Many in the FOSS community disagree with that approach, with a strong rejection of such practices, suggesting people go for more open options for their operating systems and applications, and I agree with them.
Unfortunately, that same approach has now affected many Linux distribution users, who were sent scampering searching for a fix to a problem caused by a Windows update (who would've expected that?).
First spotted by Ars Technica, a monthly Windows update pushed on August 13 that included a fix to a two-year-old vulnerability, CVE-2022-2601, with an 8.6 CVSS severity rating, caused dual-boot systems with Windows and Linux distros to not boot.
That fix was meant to tackle an issue with the GRUB bootloader, which allowed malicious actors from carrying out-of-bound writes, and possibly bypass secure boot.
But, it caused some collateral damage in the process. After updating, many users, including users of Ventoy, and Ubuntu 24.04, reported that they were shown the following error:
Verifying shim SBAT data failed: Security Policy Violation
This update installed an SBAT, which is an acronym for Secure Boot Advanced Targeting, a Linux-focused method for discarding various components in the boot path using generation numbers embedded into the EFI binaries. (apologies for the jargon)
However, this mechanism was meant to run with devices only running Windows, and, according to Microsoft, this should not have caused any issues on dual-boot systems, at least on newer Linus distributions.
But, as we know already, it did. 😑
Following these revelations, in a statement, Microsoft mentioned that they were aware of “some secondary boot scenarios are causing issues for some customers”, and that they were working with their Linux partners to investigate and address the issue.
Thankfully, the community has come to the rescue, with manutheeng, a member of the Linux Mint forums, finding a solution for Ubuntu in an old post on the Ubuntu forums.
The Solution
First, disable Secure Boot from the UEFI menu.
Then, log into Ubuntu with the user of your choice.
Now, open a terminal and execute the following command:
sudo mokutil --set-sbat-policy delete
After that, reboot your PC to see the changes.
Now, if you'd like, you can re-enable Secure Boot from the UEFI menu.
The above steps should also work with any Ubuntu-based Linux distribution. If that doesn't work, then you might be facing what a Framework laptop user faced.
Closing Thoughts
If dual-boot systems were more common, then this issue would've been treated with more haste, like the CrowdStrike incident that took place last month, but that was not Microsoft's fault.
So, it's better than nothing. 🙂
Ultimately, there's still the matter of Secure Boot being an absolute mess, that has left many people questioning whether this could've been implemented in a better way.
I think that it could've, the PC industry rushed its implementation before it was ready.
💬 What about you? Were you impacted by these Windows update shenanigans? Let me know below!
