That grub has security vulnerabities does not surprise me, it's just too big. That's why Lennart recommends systemd-boot. (Incidently a Microsoft employee, but I have no information that he would have been involved in these discoveries.) U-boot again is typical embedded software, a field generally known more for hacks than strict programming practices. So I cannot say I would be shocked. That said, I would be surprised if systemd-boot or Microsoft's loader had zero vulnerabilities hiding somewhere.
When does Microsoft open their source for searching vulnerabilities?
GRUB is too big? Maybe because it's 30 years old and can boot at least 11 architectures.
...and what systemd-boot is? A UEFI only boot menu which gets its data from UEFI only.
I mean comparing two different things and claiming the more featured one too big is mental gymnastics to put it politely.
GRUB having vulnerabilities is not surprising, esp. when the thing is written at an age where computers were completely different things, programming and requirements wise, but insinuating that systemd-boot is the ultimate replacement is, eh, a bit underhanded. Esp. when it comes from Lennart, whose systemd is too big and encompassing for an init system.
To start with, security of "secure boot" there is a joke because anyway all os have to be signed by Microsoft itself. So anyone with they certificate key can do whatever they want.
And btw, not that long ago it was released by researchers than more than 200 platforms from diverse but main laptops and servers manufacturers were still using leaked keys for signing their boot loaders...
> security of "secure boot" there is a joke because anyway all os have to be signed by Microsoft itself.
Is Apple a joke because they sign the root of trust for their devices? Someone has to be the root authority. Honestly I trust MS more than I do Google or VerisignDigicert. They are the least likely to intentionally break things.
The reason MS controls the root and not Red Hat etc. is because the Linux camp spent years arguing back and forth about exactly how much they hate secure boot - like an HOA arguing over paint colors - instead of presenting solutions.
> So anyone with they certificate key can do whatever they want.
this is literally how PKI works
Somehow I think MS put a little more thought into their PKI design than whatever you're trying to convey here. What were the other options? Store it on a Yubikey sewn into rms's beard?
People are quick to dismiss secure boot simply because they refuse to understand it.
You can enroll your own certificates as long as you have unlocked firmware. However, in order for vendor ISOs to boot without modification, they need to be signed by some trusted root beyond your control.
Not really? The entire use model could be "just show a prompt on first use" which literally MS is trying to kill, because oh it just so happens the status quo basically benefits them and nobody else.
I'm not sure what's being complained about here. Most PCs (still) come with Windows, so "first use" will have occurred before you obtained the computer. A motherboard bought separately usually comes unlocked so you can remove the Microsoft certificate if you don't want to trust it anymore. If you're saying that unlocked parts bought individually should not come with any certificates trusted out of the box, I don't necessarily disagree, but this would be a regression in security and convenience for the average user, so it's unlikely to be adopted.
Or just show a prompt whether you try the first time you try to boot something with a signature that is not recognized, like what a million slightly-less-consumer-hostile appliances out there do. This _adds_ convenience to the user, and it is hardly a regression in security.
If there is no pre-existing trusted root, the certificate presented is meaningless to laypeople. There's no way for the average person to know whether to press yes or no to it, as they're not about to check the SHA256 fingerprint against some obscure web page they have to access from another device. Nobody gets official media anymore; everything is burned, flashed, or second hand. Self-signed is no better than unsigned if you don't know how or don't bother to check.
Just to be clear, I'm not saying you shouldn't be able to boot something you trust on a device you own, just that it's completely reasonable to have Microsoft's certificate preloaded.
This is as ridiculous as it gets -- so malicious Linux install media is the problem you want to defend against? When has this _ever_ been a problem? And more importantly -- why is this ridiculous problem so important the solution must be giving MS even more monopoly abusing powers?
People may use pendrives, but even if they literally google "Linux install" and click on the first result they are getting the media from the correct website. One could even claim it is in practice even a better situation than getting it from a random, even if reputable magazine as it was common 20 years ago.
The certificate is not meaningless; it still identifies the same publisher. E.g. if you already trusted Suse once, you do not get the same prompt again.
If you really cannot reliably identify the contents of your install media for the very first installation, what do you want to do here? And why is Windows having the advantage even improving the situation at all? With no dbx, you have a myriad of exploitable Windows versions ready to be used in your 'compromised' Windows install media. And due to the draconianess of the secure boot lockdown, most Linux users will either disable secure boot entirely, add the MS UEFI CA (with the extra bazillion of now non-MS backdoors that entails), or roll their own PK/MOK. In all 3 cases, your compromised install media 'wins' and secure boot has been useless. These are not dumb users precisely...
As usual with secure boot, the threat vectors it 'defends' against are very farfetched, made redundant with a plenitude of easier attack vectors that secure boot will not protect against, and anyway whatever protection SB may give is defeated entirely by comically easy methods (e.g. using a legit windows install media to simply boot the pc with your fake fullscreen windows install/logon dialog while you clone the bitlocker encrypted disk. Bonus points if you use that same computers' recovery partition instead of external install media, which was still an unpatched hole just a couple years ago) precisely because SB basically defaults to "trust anything from MS" instead of trusting only what the user wants it to trust. It also happens that MS not only benefits significantly from this current implementation but also has repeateadly used it to push other OSes away.
This is not about Linux vs Windows and it's perfectly possible (in fact, much more likely) to ship malware via Windows-derived install media. Secure Boot does not protect against post-boot vulnerabilities but it does protect against persisting those vulnerabilities through bootkits. I do not endorse any position which makes claims about the security benefits of Secure Boot beyond simply protecting the boot process. I also don't think Secure Boot is flawless or not in need of revision. I'm also not talking about protecting power users or otherwise knowledgeable people, but rather the average user.
The default trust list can certainly be expanded beyond just Microsoft, but as the vast majority of PC users are running Windows, obviously Microsoft should be in there. In the real world, install media gets shared around and reused as much as it gets freshly downloaded for every install. And even a fresh download on a pwned PC can be modified in situ or when imaged so it can't necessarily be trusted anyway. Even if default-trusting Microsoft has allowed exploits like you describe, that is not a regression compared to not using Secure Boot, and most (all?) of those machines had Windows installed already so would've been trusting Microsoft anyway.
There's an avenue of argument here about whether Secure Boot as currently architected is really offering enough benefit to even justify its existence, but that seems tangential at best to the question of whose certificates to trust. The ideological and anticompetitive issues about Microsoft are not relevant to the point I'm making.
All evidence has always pointed to the purpose of Microsoft SecureBoot being introduced primarily as an obstacle to continued use of Windows 7 as well as Linux on PC's going forward when Windows 8 PC's were released.
Not like there's any question.
Overwhelmingly more so than for "security" purposes.
Any lesser understanding of Microsoft SecureBoot, well, I understand.
I've seen that kind of that kind of refusal before.
Basically a little bit yes. Especially for an entity located in US and with strong links to the basic government.
But in the case of secure boot, this is worse, because Microsoft is just a "software" editor. But its root certificate and probably a few random others are distributed in countless of devices produced by manufacturers unrelated to them, but also, a few number of software distributors will also have subkeys to be able to sign their os/software. All of that, with zero transparency.
And in the end, if I buy a Lenovo laptop, to have Linux OS running on it, there is no reason and no trust to have my OS be signed by Microsoft, that has the key to run whatever they want on my laptop. Think about it and you will see that it makes no sense at all, if you don't trust Microsoft for your OS, to have to trust them for ensuring a secure boot...
Technically you can revoke the default root of trust and install your own.
Then manually sign your bootloader.
This feature is available at least in my Gigabyte mainboard, but is not particularly easy to use, which is why bootloaders come pre-signed with a known root of trust.
There's nothing stopping the installer from generating the root of trust on the fly, except for the default settings in many machines.
Can also preload measurements for hardware while at it so that nobody swaps a PCIe device for an evil twin.
Some PCs are able to use your own keys, which can be used to sign your bootloader. This has worked well for me with various HP computers (EliteBooks and EliteDesks). One of those, which only runs Linux, will refuse to boot the Windows installer. On my work laptop, I've also added the Windows key (not the 3rd party one) so I can dual-boot.
I understand some computers may not support this as well, so YMMV.
Well if Microsoft was as serious about security as they could be, they would have made sure the NT6 boot routine would boot Linux without needing Grub a long time ago.
With the resources they have, and these unique findings AI has helped them discover, they should now be in the ideal position to rapidly correct this deficiency in their own bootloader, so that nobody will ever need to use Grub again.
With this level of expertise, now enhanced by AI, and so much effort already behind them so far, it shouldn't take much to push this over the finish line, provided they have an effective enough organization when it comes to enhancing the security of PC users overall. After all, they don't even have to worry about addressing Macs.
I know the engineers are brilliant enough by far, and with nothing holding them back, we should be able to expect a minor revision of of the NT bootloader like this to be arriving any day now.
According to what I see in the article, this would be one of the most timely & useful security patches to show up on Windows Update, I hope they don't drop the ball on this one.
Patch Tuesday is next week but they seem so close they could probably push this critical correction out before that, so watch for it :)
I've always thought it was exceptionally clear that Microsoft emphatically does not want you to dualboot.
That's why we got secure boot and why windows absolutely clobbers any other bootloaders during install, updates, and random points in between. It's why we have WSL.
I'll bet good money that Microsoft never even considers what you propose. It's antithetical to the mission of "lock all possible users into ad revinue streams". Microsoft won't get their windows ad impressions if they allow you to use a different OS on the hardware you own.
Good example of a nonideal approach, but I would settle for that since at least it's better than how UEFI has developed so far.
I think the "default" sequence for new (naturally Windows-preinstalled) PC's is simply UEFI > NT6 bootloader > Windows.
On mainstream PC's like this, for users to include Linux if they want to (without disturbing Windows) it should be a straightforward option to install Linux to its own partition, and end up with UEFI > NT6 bootloader > Windows or Linux. Your choice by paying attention to the built-in NT6 bootmenu upon power up, whenever you don't want to boot automatically to the default OS.
With exactly the same workflow as you used to be able to with BIOS. I know there are subsurface differences, but always hold out hope that maybe someone will be advanced enough to handle this much abstraction ;)
This deficiency was not a factor before UEFI struck, since the NT6 bootloader would start Linux under BIOS with no problem. Still will, and Grub will still start Windows, working smoother than ever even in UEFI. NT5 bootloader was even good enough, and you can probably go back to NT3.
>Windows supports setting a one time boot using a UEFI BootNext NVRAM variable, directly boots shim.efi, doesn't involve bootmgr.efi
Even better than that, both Windows and Linux are complete enough as an OS, that if either of their bootloaders are properly installed & configured, then no NVRAM variables need to be depended on whatsoever. Those variables are functionally just a shortcut or fallback which can compensate for lingering defects.
Plus I never thought Grub was required, I always prefer Syslinux.
No matter what, there's not supposed to be any need for a shim.
>end up with UEFI > NT6 bootloader > Windows or Linux
I don't see any advantage to involving Microsoft in the boot process.
>paying attention to the built-in NT6 bootmenu
UEFI firmware vendors provide a boot manager (the UI) for choosing what installed OS to boot. Apple has offered a graphical boot manager (option key at the boot chime) since forever.
NT6 isn't free or open source software so I don't see the various Linux projects wanting NT6 involved at all, in either the single or dual boot use case.
But in effect you're proposing different boot paths, and different UI/UX depending on whether the system is Linux-only or dual boot Windows Linux.
>This deficiency was not a factor before UEFI struck
I can't tell what deficiency you think UEFI has that BIOS didn't have. But maybe you don't like specs? Or are you referring to the much latter added UEFI Secure Boot?
>No matter what, there's not supposed to be any need for a shim.
You seem to think Microsoft wants to be in the business of executing arbitrary and unsigned code, despite all efforts proving the opposite.
>I don't see any advantage to involving Microsoft in the boot process.
Good point. Me neither, never have,
But if they're already there within the PC in some way or another, ideally they should gracefully be able to accomodate Linux under UEFI as easily as it still works when using BIOS.
>in effect you're proposing different boot paths, and different UI/UX depending on whether the system is Linux-only or dual boot Windows Linux.
Not proposing. Been living it for decades. It's only broken under UEFI.
Even on my average pure Windows machine, I normally have about 4 distinct boot paths for each OS using various instances of the NT6 bootloader. Not counting the option of whipping up an emergency boot floppy which can still be made for modern Windows use if all else failed.
Experience has shown, the more viable boot paths, and the fewer obstacles, the greater reliability.
>You seem to think Microsoft wants to be in the business of executing arbitrary and unsigned code
Nope, that's just how they started out and ended up outgrowing IBM. I remember it well, those days are long over.
Likewise, there should never have been any need for Linux to involve any Microsoft code or signing, like SecureBoot, in order to perform on the most secure new PC's without requiring any different default UEFI settings than Windows.
It’s not an article about vulnerable boot loaders. It’s an ad for their AI offering. That they turned their AI loose on some boot loaders is not material to the intended affect of the ad.
I think that finding and fixing this many vulns is a worthwhile achievement, no matter how they did it. But it does detract from the quality of the article that they are pushing CoPilot so heavily.
Did you read the OP link ? They go in far more details than just presenting what they did with AI, and they actually found several exploitable vulnerabilities, not just with AI, but with other techniques such as code analyzing or fuzzing.
AI is in he title, but the content is not entirely revolving around it.
I’ve been hearing for 20 years that any second now Secure Boot be used to block people from installing Linux. It has never happened, not even on Microsoft’s 1st-party hardware. Give it a rest, yeah?
There is a deal between antitrust regulators (would need to look up who exactly...) and Microsoft that secure boot on x86 must allow to install your own keys and thereby alternative operating systems. It does not cover any other architecture, so ARM devices can be and have been locked. Just Microsoft is not very relevant in the ARM space so it's less disturbing. (Others are locking ARM, too. But that's a different discussion.)
Also I would not trust on the current US administration to keep deals that limit US corporations in force forever.
I have used secure boot to secure Linux systems, so it is useful for Linux users. But the danger that oligopolists will misuse it is not unreal.
The US is not the only government with sway over US tech companies, and the OS market is now substantially more diverse than when secure boot on x86 was first introduced ~15 years ago.
Never say never, but I just don't see how the option for one to boot an alternative OS on the vast majority of commodity hardware is going to be rolled back any time in the foreseeable future.
It is 2025. I go to a random store and buy a laptop. It comes with Windows. I put on a pendrive of a Linux distribution that claims to be secure boot compatible. I reboot. It doesn't work -- it goes straight into Windows.
I see the BIOS offers a boot menu -- "press F12 during boot to select boot device", it clearly says during POST. I press F12. I choose the USB Sandisk whatever pendrive where my Linux distribution is. It doesn't work -- it still boots straight into Windows. There's no error message whatsoever, it just goes into Windows.
I continue to peruse the BIOS. I find an option to wipe the internal storage. I do it. There is no Windows anymore. I plug in the pendrive and reboot the system. It doesn't work -- it goes straight into a BIOS setup page called "Recovery". It offers me to do hardware diagnostics, as if I had a broken laptop screen or something. Not once it mentions anything about there having been a secure boot failure.
What is this if not blocking people from installing Linux ? All of this used to frigging work. I would put the pendrive and it would boot Linux no questions asked. Or at worst I would need to hold some key while booting. Or in worst case situation I could use _frigging Windows itself_ to boot from a difference device on next boot (they STILL offer this). It. Used. To. Work.
At the end and by pure luck I find out that, like many other computers sold today, and as per the "recommendation" of Microsoft, this computer does not have the "Microsoft UEFI CA key" enabled by default. It is completely logical that I have to enable something about Microsoft UEFI on my BIOS to allow Linux to boot. Completely logical.
Ah, and I get a million warnings while doing that, clearly saying that "This will reduce the security of my computer". I got less warnings when I wiped the disks than when I enabled the MS UEFI CA. Seriously. Don't even think of trying to disable Secure Boot . Your will lose your data faster than if you literally sanitize your disks. Apparently.
And worst of it, the poor distributions that are "Secure Boot" compatible needed to _castrate_ themselves in order for MS to sign them. For example, Suse doesn't support friggin' _hibernation_ anymore. No more NVIDIA drivers. No more loading kernel modules. "Root" is no longer "root" if you boot with Secure Boot. Lockdown is mandatory despite the fact that Linus himself said it was a stupid dumb move to tie Lockdown to Secure Boot status. It happened anyway. That is the power of MS.
And despite the mandatory castrating, MS still goes and ALTERS THE DEAL, since now Secure Boot devices ANYWAY STILL NO LONGER BOOT LINUX DISTRIBUTIONS BY DEFAULT.
Call this whatever you want. I call it Secure Boot working as intended. And that is the problem.
Viruses that bypass the OS and work over your boot loader. They created this to solve other problems they also created. Every famous rootkit I can remember was due to sloppy coding or flat out intentional backdoors in their product (Sony).
Then they help get UEFI off the ground to essentially really broaden the attack surface they just "solved."
> Open sores zealots have been spewing that nonsense for 15+ years
Pro tip: If you open like that, people won't take you seriously even if you happen to have a point.
> and all it has done is held back Linux from providing the security benefits of Secure Boot and transparent full disk encryption in an easy-to-administer
Also, we have that. In fact, I accidentally reenabled secure boot on a Linux box recently and only even noticed because it broke the nvidia driver. The closed source driver. If only I'd been more dedicated to only running FOSS then it would have worked.
And, if your distro had you enroll a MOK key and failed to bless all your kernel modules, FOSS or not, then it's still broken. That was also my experience the last time I tried, with the module(s) required to get a Coral TPU going. There existed a hook script that was supposed to do the needful but it wasn't working on that module and I couldn't make sense of it.
I don't think either of you are persuadable, actually.
I didn't have to enroll anything; I assume they are signed by MS. I'm pretty sure nvidia drivers are dkms, and I think they have to be for legal reasons (off the top of my head and IANAL so grain of salt) so I don't view that as a fault because they can't do otherwise.
if you want to security, I think a generic boot loader isn't really a realistic target. A boot loader should be specific to the hardware. If you want a generic boot loader, you need to integrate perfected boot loaders for each hardware.
downvotes and no replies but I know I'm correct. buffer overflows and reproducibility in builds is only the smell of a secure bootloader, real secure bootloading is not going to happen in Grub2 without a total rewrite and a boot system that's built to be correct FIRST instead of recoverable for bad states with internal logging and exception handling.
That grub has security vulnerabities does not surprise me, it's just too big. That's why Lennart recommends systemd-boot. (Incidently a Microsoft employee, but I have no information that he would have been involved in these discoveries.) U-boot again is typical embedded software, a field generally known more for hacks than strict programming practices. So I cannot say I would be shocked. That said, I would be surprised if systemd-boot or Microsoft's loader had zero vulnerabilities hiding somewhere.
When does Microsoft open their source for searching vulnerabilities?
>That's why Lennart recommends systemd-boot.
The creator of SystemD recommends systemd-boot? Seems legit and unbiased.
There is probably an overlong yet superficial, easy to read post on his blog about it.
Yeah, and because grub is too big. Says systemd, of all places.
Pulseaudio still doesn't work reliably.
I think Pipewire has completely replaced Pulseaudio where it matters.
Yes, PulseAudio works great since it's actually PipeWire.
systemd-boot is much smaller than grub.
GRUB is too big? Maybe because it's 30 years old and can boot at least 11 architectures.
...and what systemd-boot is? A UEFI only boot menu which gets its data from UEFI only.
I mean comparing two different things and claiming the more featured one too big is mental gymnastics to put it politely.
GRUB having vulnerabilities is not surprising, esp. when the thing is written at an age where computers were completely different things, programming and requirements wise, but insinuating that systemd-boot is the ultimate replacement is, eh, a bit underhanded. Esp. when it comes from Lennart, whose systemd is too big and encompassing for an init system.
It's the pot calling the kettle black, heh.
To start with, security of "secure boot" there is a joke because anyway all os have to be signed by Microsoft itself. So anyone with they certificate key can do whatever they want.
And btw, not that long ago it was released by researchers than more than 200 platforms from diverse but main laptops and servers manufacturers were still using leaked keys for signing their boot loaders...
> security of "secure boot" there is a joke because anyway all os have to be signed by Microsoft itself.
Is Apple a joke because they sign the root of trust for their devices? Someone has to be the root authority. Honestly I trust MS more than I do Google or VerisignDigicert. They are the least likely to intentionally break things.
The reason MS controls the root and not Red Hat etc. is because the Linux camp spent years arguing back and forth about exactly how much they hate secure boot - like an HOA arguing over paint colors - instead of presenting solutions.
> So anyone with they certificate key can do whatever they want.
this is literally how PKI works
Somehow I think MS put a little more thought into their PKI design than whatever you're trying to convey here. What were the other options? Store it on a Yubikey sewn into rms's beard?
People are quick to dismiss secure boot simply because they refuse to understand it.
>Someone has to be the root authority
No-one has to be, and it certainly doesn't need to be anyone but the owner of the machine.
> No-one has to be, and it certainly doesn't need to be anyone but the owner of the machine.
Technically the web should work with self-signed certificates. But that is likewise impractical.
You can enroll your own certificates as long as you have unlocked firmware. However, in order for vendor ISOs to boot without modification, they need to be signed by some trusted root beyond your control.
Not really? The entire use model could be "just show a prompt on first use" which literally MS is trying to kill, because oh it just so happens the status quo basically benefits them and nobody else.
I'm not sure what's being complained about here. Most PCs (still) come with Windows, so "first use" will have occurred before you obtained the computer. A motherboard bought separately usually comes unlocked so you can remove the Microsoft certificate if you don't want to trust it anymore. If you're saying that unlocked parts bought individually should not come with any certificates trusted out of the box, I don't necessarily disagree, but this would be a regression in security and convenience for the average user, so it's unlikely to be adopted.
Or just show a prompt whether you try the first time you try to boot something with a signature that is not recognized, like what a million slightly-less-consumer-hostile appliances out there do. This _adds_ convenience to the user, and it is hardly a regression in security.
If there is no pre-existing trusted root, the certificate presented is meaningless to laypeople. There's no way for the average person to know whether to press yes or no to it, as they're not about to check the SHA256 fingerprint against some obscure web page they have to access from another device. Nobody gets official media anymore; everything is burned, flashed, or second hand. Self-signed is no better than unsigned if you don't know how or don't bother to check.
Just to be clear, I'm not saying you shouldn't be able to boot something you trust on a device you own, just that it's completely reasonable to have Microsoft's certificate preloaded.
This is as ridiculous as it gets -- so malicious Linux install media is the problem you want to defend against? When has this _ever_ been a problem? And more importantly -- why is this ridiculous problem so important the solution must be giving MS even more monopoly abusing powers?
People may use pendrives, but even if they literally google "Linux install" and click on the first result they are getting the media from the correct website. One could even claim it is in practice even a better situation than getting it from a random, even if reputable magazine as it was common 20 years ago.
The certificate is not meaningless; it still identifies the same publisher. E.g. if you already trusted Suse once, you do not get the same prompt again.
If you really cannot reliably identify the contents of your install media for the very first installation, what do you want to do here? And why is Windows having the advantage even improving the situation at all? With no dbx, you have a myriad of exploitable Windows versions ready to be used in your 'compromised' Windows install media. And due to the draconianess of the secure boot lockdown, most Linux users will either disable secure boot entirely, add the MS UEFI CA (with the extra bazillion of now non-MS backdoors that entails), or roll their own PK/MOK. In all 3 cases, your compromised install media 'wins' and secure boot has been useless. These are not dumb users precisely...
As usual with secure boot, the threat vectors it 'defends' against are very farfetched, made redundant with a plenitude of easier attack vectors that secure boot will not protect against, and anyway whatever protection SB may give is defeated entirely by comically easy methods (e.g. using a legit windows install media to simply boot the pc with your fake fullscreen windows install/logon dialog while you clone the bitlocker encrypted disk. Bonus points if you use that same computers' recovery partition instead of external install media, which was still an unpatched hole just a couple years ago) precisely because SB basically defaults to "trust anything from MS" instead of trusting only what the user wants it to trust. It also happens that MS not only benefits significantly from this current implementation but also has repeateadly used it to push other OSes away.
This is not about Linux vs Windows and it's perfectly possible (in fact, much more likely) to ship malware via Windows-derived install media. Secure Boot does not protect against post-boot vulnerabilities but it does protect against persisting those vulnerabilities through bootkits. I do not endorse any position which makes claims about the security benefits of Secure Boot beyond simply protecting the boot process. I also don't think Secure Boot is flawless or not in need of revision. I'm also not talking about protecting power users or otherwise knowledgeable people, but rather the average user.
The default trust list can certainly be expanded beyond just Microsoft, but as the vast majority of PC users are running Windows, obviously Microsoft should be in there. In the real world, install media gets shared around and reused as much as it gets freshly downloaded for every install. And even a fresh download on a pwned PC can be modified in situ or when imaged so it can't necessarily be trusted anyway. Even if default-trusting Microsoft has allowed exploits like you describe, that is not a regression compared to not using Secure Boot, and most (all?) of those machines had Windows installed already so would've been trusting Microsoft anyway.
There's an avenue of argument here about whether Secure Boot as currently architected is really offering enough benefit to even justify its existence, but that seems tangential at best to the question of whose certificates to trust. The ideological and anticompetitive issues about Microsoft are not relevant to the point I'm making.
All evidence has always pointed to the purpose of Microsoft SecureBoot being introduced primarily as an obstacle to continued use of Windows 7 as well as Linux on PC's going forward when Windows 8 PC's were released.
Not like there's any question.
Overwhelmingly more so than for "security" purposes.
Any lesser understanding of Microsoft SecureBoot, well, I understand.
I've seen that kind of that kind of refusal before.
Basically a little bit yes. Especially for an entity located in US and with strong links to the basic government.
But in the case of secure boot, this is worse, because Microsoft is just a "software" editor. But its root certificate and probably a few random others are distributed in countless of devices produced by manufacturers unrelated to them, but also, a few number of software distributors will also have subkeys to be able to sign their os/software. All of that, with zero transparency.
And in the end, if I buy a Lenovo laptop, to have Linux OS running on it, there is no reason and no trust to have my OS be signed by Microsoft, that has the key to run whatever they want on my laptop. Think about it and you will see that it makes no sense at all, if you don't trust Microsoft for your OS, to have to trust them for ensuring a secure boot...
Technically you can revoke the default root of trust and install your own.
Then manually sign your bootloader.
This feature is available at least in my Gigabyte mainboard, but is not particularly easy to use, which is why bootloaders come pre-signed with a known root of trust. There's nothing stopping the installer from generating the root of trust on the fly, except for the default settings in many machines.
Can also preload measurements for hardware while at it so that nobody swaps a PCIe device for an evil twin.
Some PCs are able to use your own keys, which can be used to sign your bootloader. This has worked well for me with various HP computers (EliteBooks and EliteDesks). One of those, which only runs Linux, will refuse to boot the Windows installer. On my work laptop, I've also added the Windows key (not the 3rd party one) so I can dual-boot.
I understand some computers may not support this as well, so YMMV.
Here is the article I was referring to: https://arstechnica.com/security/2024/07/secure-boot-is-comp...
"To demonstrate how efficient our product, CoPilot is, we've decided to use it to uncover vulnerabilities in competing products."
Gee, how clever and thoughtful.
The link for U-Boot CVE-2025-26729 is actually 2 separate links that lead to different vulnerabilities depending on which half of it you click.
Odd. I wonder if the article was written by AI.
Well if Microsoft was as serious about security as they could be, they would have made sure the NT6 boot routine would boot Linux without needing Grub a long time ago.
With the resources they have, and these unique findings AI has helped them discover, they should now be in the ideal position to rapidly correct this deficiency in their own bootloader, so that nobody will ever need to use Grub again.
With this level of expertise, now enhanced by AI, and so much effort already behind them so far, it shouldn't take much to push this over the finish line, provided they have an effective enough organization when it comes to enhancing the security of PC users overall. After all, they don't even have to worry about addressing Macs.
I know the engineers are brilliant enough by far, and with nothing holding them back, we should be able to expect a minor revision of of the NT bootloader like this to be arriving any day now.
According to what I see in the article, this would be one of the most timely & useful security patches to show up on Windows Update, I hope they don't drop the ball on this one.
Patch Tuesday is next week but they seem so close they could probably push this critical correction out before that, so watch for it :)
I've always thought it was exceptionally clear that Microsoft emphatically does not want you to dualboot.
That's why we got secure boot and why windows absolutely clobbers any other bootloaders during install, updates, and random points in between. It's why we have WSL.
I'll bet good money that Microsoft never even considers what you propose. It's antithetical to the mission of "lock all possible users into ad revinue streams". Microsoft won't get their windows ad impressions if they allow you to use a different OS on the hardware you own.
I'll be pissed if they broke my Ubuntu instance ...again under the guise of security.
I don't understand why you think GRUB is required. Or what boot sequence (or use case) involves UEFI > NT6 > GRUB > linux.
Are you wanting bootmgr.efi to learn how to read arbitrary Linux filesystems, bootloader configurations, and EFISTUB? Why?
Windows supports setting a one time boot using a UEFI BootNext NVRAM variable, directly boots shim.efi, doesn't involve bootmgr.efi
>what boot sequence (or use case) involves UEFI > NT6 > GRUB > linux.
Good example of a nonideal approach, but I would settle for that since at least it's better than how UEFI has developed so far.
I think the "default" sequence for new (naturally Windows-preinstalled) PC's is simply UEFI > NT6 bootloader > Windows.
On mainstream PC's like this, for users to include Linux if they want to (without disturbing Windows) it should be a straightforward option to install Linux to its own partition, and end up with UEFI > NT6 bootloader > Windows or Linux. Your choice by paying attention to the built-in NT6 bootmenu upon power up, whenever you don't want to boot automatically to the default OS.
With exactly the same workflow as you used to be able to with BIOS. I know there are subsurface differences, but always hold out hope that maybe someone will be advanced enough to handle this much abstraction ;)
This deficiency was not a factor before UEFI struck, since the NT6 bootloader would start Linux under BIOS with no problem. Still will, and Grub will still start Windows, working smoother than ever even in UEFI. NT5 bootloader was even good enough, and you can probably go back to NT3.
>Windows supports setting a one time boot using a UEFI BootNext NVRAM variable, directly boots shim.efi, doesn't involve bootmgr.efi
Even better than that, both Windows and Linux are complete enough as an OS, that if either of their bootloaders are properly installed & configured, then no NVRAM variables need to be depended on whatsoever. Those variables are functionally just a shortcut or fallback which can compensate for lingering defects.
Plus I never thought Grub was required, I always prefer Syslinux.
No matter what, there's not supposed to be any need for a shim.
>end up with UEFI > NT6 bootloader > Windows or Linux
I don't see any advantage to involving Microsoft in the boot process.
>paying attention to the built-in NT6 bootmenu
UEFI firmware vendors provide a boot manager (the UI) for choosing what installed OS to boot. Apple has offered a graphical boot manager (option key at the boot chime) since forever.
NT6 isn't free or open source software so I don't see the various Linux projects wanting NT6 involved at all, in either the single or dual boot use case.
But in effect you're proposing different boot paths, and different UI/UX depending on whether the system is Linux-only or dual boot Windows Linux.
>This deficiency was not a factor before UEFI struck
I can't tell what deficiency you think UEFI has that BIOS didn't have. But maybe you don't like specs? Or are you referring to the much latter added UEFI Secure Boot?
>No matter what, there's not supposed to be any need for a shim.
You seem to think Microsoft wants to be in the business of executing arbitrary and unsigned code, despite all efforts proving the opposite.
>I don't see any advantage to involving Microsoft in the boot process.
Good point. Me neither, never have,
But if they're already there within the PC in some way or another, ideally they should gracefully be able to accomodate Linux under UEFI as easily as it still works when using BIOS.
>in effect you're proposing different boot paths, and different UI/UX depending on whether the system is Linux-only or dual boot Windows Linux.
Not proposing. Been living it for decades. It's only broken under UEFI.
Even on my average pure Windows machine, I normally have about 4 distinct boot paths for each OS using various instances of the NT6 bootloader. Not counting the option of whipping up an emergency boot floppy which can still be made for modern Windows use if all else failed.
Experience has shown, the more viable boot paths, and the fewer obstacles, the greater reliability.
>You seem to think Microsoft wants to be in the business of executing arbitrary and unsigned code
Nope, that's just how they started out and ended up outgrowing IBM. I remember it well, those days are long over.
Likewise, there should never have been any need for Linux to involve any Microsoft code or signing, like SecureBoot, in order to perform on the most secure new PC's without requiring any different default UEFI settings than Windows.
> nobody will ever need to use Grub again.
I mean, I replaced Grub with systemd-boot awhile back...
Title: Analyzing open-source bootloaders: Finding vulnerabilities faster with AI
Nice to see Microsoft boosting open source operating system practices. (May be a little anti monopoly politicking, ahem.)
Makes me trust open source operating systems more!
It’s not an article about vulnerable boot loaders. It’s an ad for their AI offering. That they turned their AI loose on some boot loaders is not material to the intended affect of the ad.
I think that finding and fixing this many vulns is a worthwhile achievement, no matter how they did it. But it does detract from the quality of the article that they are pushing CoPilot so heavily.
Did you read the OP link ? They go in far more details than just presenting what they did with AI, and they actually found several exploitable vulnerabilities, not just with AI, but with other techniques such as code analyzing or fuzzing.
AI is in he title, but the content is not entirely revolving around it.
agree it's an ad
but if they sent the AI through all that ancient code and that's all they found it's not a good advertisement
This whole thing is weird: submitting account registered 3 days ago, no other activity than this link added on coincidentally, MS anniversary.
[dead]
What they probably don’t tell you is that they also found critical vulnerabilities in their own boot loader and fixed them silently
[flagged]
I’ve been hearing for 20 years that any second now Secure Boot be used to block people from installing Linux. It has never happened, not even on Microsoft’s 1st-party hardware. Give it a rest, yeah?
There is a deal between antitrust regulators (would need to look up who exactly...) and Microsoft that secure boot on x86 must allow to install your own keys and thereby alternative operating systems. It does not cover any other architecture, so ARM devices can be and have been locked. Just Microsoft is not very relevant in the ARM space so it's less disturbing. (Others are locking ARM, too. But that's a different discussion.)
Also I would not trust on the current US administration to keep deals that limit US corporations in force forever.
I have used secure boot to secure Linux systems, so it is useful for Linux users. But the danger that oligopolists will misuse it is not unreal.
The US is not the only government with sway over US tech companies, and the OS market is now substantially more diverse than when secure boot on x86 was first introduced ~15 years ago.
Never say never, but I just don't see how the option for one to boot an alternative OS on the vast majority of commodity hardware is going to be rolled back any time in the foreseeable future.
it's like the antivax - we haven't had an outbreak of $x in $y years, why do we still need to be vaccinated?
> It has never happened, not even on Microsoft’s 1st-party hardware
It did on Windows RT devices.
Meanwhile these same people are tripping over each other to buy ARM MacBooks, which are by design extremely hostile to their cause.
It is 2025. I go to a random store and buy a laptop. It comes with Windows. I put on a pendrive of a Linux distribution that claims to be secure boot compatible. I reboot. It doesn't work -- it goes straight into Windows.
I see the BIOS offers a boot menu -- "press F12 during boot to select boot device", it clearly says during POST. I press F12. I choose the USB Sandisk whatever pendrive where my Linux distribution is. It doesn't work -- it still boots straight into Windows. There's no error message whatsoever, it just goes into Windows.
I continue to peruse the BIOS. I find an option to wipe the internal storage. I do it. There is no Windows anymore. I plug in the pendrive and reboot the system. It doesn't work -- it goes straight into a BIOS setup page called "Recovery". It offers me to do hardware diagnostics, as if I had a broken laptop screen or something. Not once it mentions anything about there having been a secure boot failure.
What is this if not blocking people from installing Linux ? All of this used to frigging work. I would put the pendrive and it would boot Linux no questions asked. Or at worst I would need to hold some key while booting. Or in worst case situation I could use _frigging Windows itself_ to boot from a difference device on next boot (they STILL offer this). It. Used. To. Work.
At the end and by pure luck I find out that, like many other computers sold today, and as per the "recommendation" of Microsoft, this computer does not have the "Microsoft UEFI CA key" enabled by default. It is completely logical that I have to enable something about Microsoft UEFI on my BIOS to allow Linux to boot. Completely logical.
Ah, and I get a million warnings while doing that, clearly saying that "This will reduce the security of my computer". I got less warnings when I wiped the disks than when I enabled the MS UEFI CA. Seriously. Don't even think of trying to disable Secure Boot . Your will lose your data faster than if you literally sanitize your disks. Apparently.
And worst of it, the poor distributions that are "Secure Boot" compatible needed to _castrate_ themselves in order for MS to sign them. For example, Suse doesn't support friggin' _hibernation_ anymore. No more NVIDIA drivers. No more loading kernel modules. "Root" is no longer "root" if you boot with Secure Boot. Lockdown is mandatory despite the fact that Linus himself said it was a stupid dumb move to tie Lockdown to Secure Boot status. It happened anyway. That is the power of MS.
And despite the mandatory castrating, MS still goes and ALTERS THE DEAL, since now Secure Boot devices ANYWAY STILL NO LONGER BOOT LINUX DISTRIBUTIONS BY DEFAULT.
Call this whatever you want. I call it Secure Boot working as intended. And that is the problem.
Microsoft isn't my favorite major multinational corporation (hint: I trust none of them), but they created this to solve actual problems.
The "problem" being "how can we create a scheme to ensure our continued dominance and control, but with plausible deniability."
> but they created this to solve actual problems.
Viruses that bypass the OS and work over your boot loader. They created this to solve other problems they also created. Every famous rootkit I can remember was due to sloppy coding or flat out intentional backdoors in their product (Sony).
Then they help get UEFI off the ground to essentially really broaden the attack surface they just "solved."
[flagged]
> Open sores zealots have been spewing that nonsense for 15+ years
Pro tip: If you open like that, people won't take you seriously even if you happen to have a point.
> and all it has done is held back Linux from providing the security benefits of Secure Boot and transparent full disk encryption in an easy-to-administer
Also, we have that. In fact, I accidentally reenabled secure boot on a Linux box recently and only even noticed because it broke the nvidia driver. The closed source driver. If only I'd been more dedicated to only running FOSS then it would have worked.
You think the person I replied to is persuadable?
And, if your distro had you enroll a MOK key and failed to bless all your kernel modules, FOSS or not, then it's still broken. That was also my experience the last time I tried, with the module(s) required to get a Coral TPU going. There existed a hook script that was supposed to do the needful but it wasn't working on that module and I couldn't make sense of it.
I don't think either of you are persuadable, actually.
I didn't have to enroll anything; I assume they are signed by MS. I'm pretty sure nvidia drivers are dkms, and I think they have to be for legal reasons (off the top of my head and IANAL so grain of salt) so I don't view that as a fault because they can't do otherwise.
I consider the ability to bypass secure boot a feature, not a bug.
if you want to security, I think a generic boot loader isn't really a realistic target. A boot loader should be specific to the hardware. If you want a generic boot loader, you need to integrate perfected boot loaders for each hardware.
downvotes and no replies but I know I'm correct. buffer overflows and reproducibility in builds is only the smell of a secure bootloader, real secure bootloading is not going to happen in Grub2 without a total rewrite and a boot system that's built to be correct FIRST instead of recoverable for bad states with internal logging and exception handling.