Ah, secure boot, the bane of many running anything other than Windows. While it’s already been found to be utterly useless by now, it’s still a requirement for Windows 11, and ever since it became part of PCs about a decade or so ago, it’s been causing headaches for people who don’t use Windows. Yesterday, Microsoft released a patch for a two-year-old vulnerability in the GRUB bootloader, and while the company claimed it would only be installed on single-boot Windows machines, that clearly wasn’t the case as right after its release, people dual-booting Linux and Windows found their Linux installations unbootable.
Tuesday’s update left dual-boot devices—meaning those configured to run both Windows and Linux—no longer able to boot into the latter when Secure Boot was enforced. When users tried to load Linux, they received the message: “Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation.” Almost immediately support and discussion forums lit up with reports of the failure.
↫ Dan Goodin at Ars Technica
The fix is both easy and hilarious: disable secure boot, and you’re good to go. You can also get a bit more technical and remove the SBAT installed by this update, but while that will allow you to keep booting with secure boot enabled, it will leave you vulnerable to the issue the SBAT was supposed to fix. The efficacy of secure boot in home environments is debatable, at best, and while I’m not going to advise anyone to just turn it off and forget about it, I think most OSNews readers can make an informed decision about secure boot by themselves. If you’re using corporate machines managed by your employer’s IT department, you obviously need to refer to them.
Microsoft itself has not yet commented on this issue, and is not responding to questions from press outlets, so we’re currently in the dark about how such a game-breaking update got out in the wild.
Regardless, this once again shows just how annoying secure boot is. In many cases, the boot problems people trying out Linux run into caused by secure boot, but of course, the blame is placed squarely on Linux, and not on secure boot itself being a hot mess.
I can venture a guess: They didn’t properly test it (or test it at all) on actual dual-boot setups because they just don’t fucking care if a few of us dual booting nerds are inconvenienced. No one in enterprise is dual booting, and enterprise is all MIcrosoft cares about when it comes to Windows security.
From Microsoft perspective it’s an unsupported option.
From OEM perspective it’s an unsupported option.
Grub bootloader booting Windows is basically an aftermarket hack. So I’d be Really surprised if they tested it at any scale. Certainly in any kind of corporate setup,dual boot is a no go. So the number of users must be vanishingly small from their perspective. Coupled with their argument “if you need a Linux app, use WSL… there is no need to dual boot”.
I dual boot multiple systems, some are Linux default others Windows 10/11, Debian, Linux Mint and Ubuntu, all laptops, all have the latest WU, Some of the systems are canaries on the Insider channel, yet none of my users or my canaries are affected. There seems to be more to this story, maybe I’ve missed something.
cpcf,
I don’t dual boot windows on any of my computers any more, but just to speculate, maybe it depends on how/when grub was installed? (Distro upgrades might leave grub untouched) Maybe there’s a difference with GPT/MBR? Maybe you are booting with CSM or disabled secure boot? Microsoft does claim they don’t apply the patch to dual boot systems so maybe they properly detected dual booting for you? It seems that more information is needed as not everyone is equally affected.
It’s important to understand: it breaks some dual boot systems, it probably needs to be a dual boot system which existed for years as well. And/or especially those Linux distributions who didn’t keep up with Grub security updates.
Microsoft basically indirectly marked vulnerable Grub versions as invalid for Secure Boot.
I do wonder if you install a grub update on the Linux distribution does it just install the package or actually update grub as the bootloader in all situations ?
I’ve seen a lot of reporting about this but it seems that most of it misses what the actual issue is. This isn’t about GRUB, it’s about the shim bootloader. shim is a minimal bootloader that is signed with Microsoft’s key and is used to then run GRUB. Most Linux distro use shim to load their own signing keys into the UEFI firmware and then boot a version of GRUB that has been signed with them. The SBAT is a list of bootloader versions that are considered vulnerable and should not be run. Typically the first bootloader should check if the subsequent ones can be run by comparing their versions to the list. Note: the SBAT versions do not correspond to the actual versions of the bootloaders, they’re just integer numbers that gets bumped by 1 if a vulnerability is found.
So here’s the catch, Microsoft distributed a SBAT update with the following entries:
sbat,1,2024010900
shim,4
grub,3
grub.debian,4
See those `shim.4` and `grub.3` entries? They mean that the bootloader should not consider `shim` and `grub` SBAT versions prior to 4 and 3 reliable, and refuse to boot them. The `shim` bootloader SBAT version 4 corresponds to shim 15.8 which was released in late ’23. Previous versions have a SBAT version number of 3 or lower. So when the shim bootloader was first loaded it would check its own SBAT version against the list of revocations… and found that it had been revoked, thus refusing to boot. That’s why it’s complaining about the self-check failed. It’s not refusing to boot using GRUB, it’s refusing to boot with itself.
Thanks, that’s a great explanation.
It seems to me that – as often – Microsoft gets blamed when it doesn’t deserve it. GRUB’s vulnerability is two years old; no currently supported Linux distribution should have installed versions of GRUB or shim that are affected by this SBAT patch.
emarsk,
User reports and the article say it affects current distros.
Some people might argue MS are justified in overseeing 3rd party components and revoking them at will, it’s their key we’re booting with after all. IMHO the real problem is that microsoft took unilateral action without giving owners any say. This is one of my gripes about secure boot since day one. Microsoft claims their update wasn’t supposed to affect existing dual boot setups when clearly it did. Even if we take them at their word that they didn’t mean to break existing dual boot setups, it leaves other questions open because other bootable media are also reportedly affected as well. Microsoft’s statement doesn’t say anything about them.
Assuming all the distros are able to work around the issues this time, what’s really to stop this from happening again? I would think that most linux users aren’t dual booting, so it minimizes the risk. But this shows that microsoft can brick linux and it’s just one of those things linux users potentially have to be careful with since it doesn’t look like MS have made a commitment not to do this again.
I feel that, as implemented & deployed, secure boot is a bad solution. Not only is it too hard for owners to take control over the chain of trust, but it’s actually very hard to tighten security too.
Most users who install/boot linux under secure boot without installing their own UEFI keys don’t realize they’re actually dependent on microsoft’s blessing to boot under microsoft’s keys. Microsoft correctly anticipated that this uproar would die down if they signed linux bootloaders under the microsoft keys that all OEMs trust. They wanted this to appear as an act of good faith, but the very idea that MS controls the keys should be extremely off-putting for informed FOSS users.
I don’t know if the breakages covered by this article were intentional or accidental, but either way it does highlight that fact that most linux users are implicitly depending on Microsoft’s graces to boot linux w/secure boot. Even though the secure boot news cycle ended many years ago all of the concerns over it are still very valid.
Wouldn’t be surprised if “fixes” are somewhat related to such fiasco. https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/ On top of that it looks like Microsoft is now under much scrutiny, due to CrowdStrike incident and Microsoft made some claims as a result, on how internal policy will be changed to take security more seriously. I guess they are now naively taking on such task and are prepared to break some eggs in the process, IMHO all to no avail. No way can Windows or other products from Microsoft be made significantly more secure in lets say next decade. On top of that if they will go on to break more corporate environments setups in the process, they will get sued and will lose clients. Corporate environments are not like home users, on where companies like Microsoft can do whatever they want and no way are users switching to lets say GNU/Linux.
Geck,
Of all your examples, not one was microsoft’s doing. Microsoft could clamp down harder on 3rd parties. Arguably that’s what they’ve done here with the SBAT patch.
Linux breakages might be more of a redhat/ubuntu/oracle problem than a microsoft problem. I don’t think they are legally mandated to provide linux support or share the MS secure boot keys.
I suspect the linux bootloaders signed under microsoft’s keys were contractually required to enforce the OS and boot integrity. Given the known grub exploit, microsoft are probably within their legal right to block it. I briefly tried to find a copy of the contract to confirm this, but I’m not sure if any linux distros have published it. Can anyone else find it?
For the record, I think the whole secureboot arrangement sucks for linux. I believe microsoft steered the secureboot working group in this direction to empower itself. It should have never come to that, secure boot should have been designed to empower owners, not vendors, but that’s the way it goes. At least most of us can turn off secure boot, it’s just a shame to have security features that are so difficult to use legitimately beyond microsoft’s keys.
This is all about Microsoft and no they won’t clamp down 3rd parties. If they do that then Windows as we know it is dead and on top of that it in my opinion wouldn’t make Windows that much more secure. Windows always was and likely always will be insecure, by design. So promises, on how things will improve in the future, they won’t.
Geck,
The “CrowdStrike incident” on windows wasn’t caused by microsoft. If you want to blame MS for that, then by logical extension do you blame the linux distros including redhat and debian because crowdstrike broke them as well?
https://www.techspot.com/news/103899-crowdstrike-also-broke-debian-rocky-linux-earlier-year.html
Likewise, do you accept that grub’s vulnerability is not microsoft’s doing either?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2601
There’s also no indication that microsoft were at fault for the inclusion of “DO NOT TRUST” secure boot keys in OEM firmware. Do you accept this fault lies with 3rd parties too?
Now I’m not a microsoft apologist, but all of your examples are legitimately 3rd party faults. Presuming that microsoft wants to protect customers from such 3rd party faults, they would have no choice but to clamp down on 3rd parties.
I’ve been pushed away from microsoft because I believe their corporate agenda goes against consumer interests. But how do you substantiate that claim that windows is insecure by design and what specifically makes linux more secure by design?
Yeah, now it’s everybody else’s fault. Ha ha.
Geck
Far be it for me to refrain from criticizing microsoft, but it needs to have merit. I asked you several questions in earnest and you answered none. Do you think linux distros deserve to be criticized over CrowdStrike? I assume you don’t want to blame the linux distros (and I would agree with you), but then why do you want to blame microsoft for crowdstrike? At the very least this discrepancy seems to warrant an explanation. The absence of an explanation just looks hypocritical.
In some previous debates you demonstrated you are not good in accepting arguments and furthermore when you run out of them you result to insulting. So no, this time i am not going down that rabbit hole. In general, feel free to claim Windows is secure by design. And that this new fiasco has nothing to do with the ones i listed and on how it’s everybody else fault. Ha ha. Get real.
Geck,
Since you are the one making the argument, the onus lies on you to defend your argument.
I’m trying to understand your mental gymnastics to blame microsoft but not linux for the CrowdStrike issue. I’ve given you opportunities to explain it, but it doesn’t look like even you have an answer. When something happens on windows, you criticize it, but when the same thing happens on linux, we cannot talk about that. Getting real: it looks like bias.
Just for the record i for sure am not making an argument that Windows is secure by design, it’s not.
Geck,
Wow, I’ve never seen such a hard pivot. Well, I think it’s fair to take that as a concession that CrowdStrike wasn’t really microsoft’s fault.
I want you to understand my reason for criticizing your arguments has nothing at all to do with a preference for microsoft. I don’t like microsoft, the more users who jump ship from windows to FOSS is great for me. But scapegoat arguments used against windows are just as wrong as the scapegoat arguments used against linux. My point being, I think there’s a good case for promoting linux with fair arguments. Arguments that are heavily biased tend not to be very persuasive.
So no word at all, about Windows being secure by design. So i will take that as us agreeing, that it’s not.
Geck,
Again, you are moving the goal posts to a new topic that has nothing at all to do with the points I was rebutting. Maybe we can discuss it as a new topic some time, but if you hadn’t blamed microsoft for external faults, I might not have disagreed with you in the first place.
We could discuss this somewhere else, but in the end we would likely come to the same conclusions, we agree. Windows is not secure by design. So lets leave it at that and we can waste time on other topics, topics that we don’t agree about.
Geck,
We can have that discussion another time.
If you will ever change your mind and will start to claim Windows is secure by design, then indeed we can discuss this further. Until then we agree. And i see no reason to discuss this further.
Geck,
You pretend that your one sided opinions are authoritative for others when they are not. It’s no wonder you are confused. Honestly, it’s not impossible to convince me to change my mind, but I am an empirical thinker and to make a strong case you need to do so in empirical terms. Acting as a totally biased religious fanatic will never help your case in the eyes of people who value evidence to draw conclusions.
Do you have any evidence that microsoft is more responsible for CrowdStrike than linux? Do you have any evidence that microsoft are responsible for the inclusion of “do not use” keys deployed in some firmwares? Do you have evidence that windows is designed less securely than linux? In the opening game you make a bunch of these grandstanding allegations out the gate, like throwing spaghetti to the wall to see what sticks. But I’m sorry to say that your mid and end game are exceptionally weak. Please please please work on that, because debating dogmatic opinions is boring as hell.
In terms of windows security model, a lot of thought went into the windows security model and being able to delegate fine grained permissions throughout the OS.
https://learn.microsoft.com/en-us/windows-hardware/drivers/driversecurity/windows-security-model
The original security designs behind unix & linux were weak by comparison. Heck most of the security was comprised of “if (uid==0)” and quaint file permission bits being overloaded for a couple purposes. Over time linux would address security deficiencies with more sophisticated security measures including access control lists, capabilities, SELinux, etc. But as to your point that “windows is not secure by design”, that seems to warrant a deeper dive. If you had said “DOS isn’t secure by design”, then sure that would be a given. But talking about windows, and winnt specifically…I think it genuinely was designed with security it mind.
And while way may debate the merits of this security, your attempt to hand-wave the whole topic as a gimme does not do the subject justice.
I wonder what MS-DOS’ power consumption is considering the OS doesn’t and cannot idle.
There are third party applications to make it do so (e.g. DOSidle by Marton Balog) but I’ve only tested them under VMWare Workstation/VirtualBox and never on real hardware.
Artem S. Tashkinov,
https://github.com/DOSAlliance/UTIL-DOSidle?tab=readme-ov-file
It just calls the hlt instruction and uses interrupts instead of polling. It should work in a VM as well as real hardware. I recall freedos having the feature built in
https://freedos-user.narkive.com/UGrcO8wU/does-freedos-make-cpu-sleep-when-idle
I think anyone running DOS should prefer freedos at this point anyway, not only because it’s FOSS, but because support & development have continued long past msdos retirement.
FreeDOS does not support UEFI, which posses a future problem for DOS on real hardware.
https://web.archive.org/web/20240101061053/https://wiki.freedos.org/wiki/index.php/UEFI
But conceivably someone might implement a BIOS layer that runs on top of UEFI. It’s certainly something I could do, but personally I lack the motivation for that, haha.
As long as emulation is good enough, I question whether there’s really much need to run DOS on real hardware beyond sentimental reasons.
Some sane discussion in LWN comments (and story):
https://lwn.net/Articles/986844/