Empowering the 'User' (hardware owner) should have always been the focus.
From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).
> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot).
The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...)
> The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
Isn't this already the status quo??
> It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...]
I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.
>IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Sounds like browserchoice.eu but even more pointless. For the normies who don't care about what keys they want installed, it doesn't make a difference. For people who want to switch to linux, it also doesn't make a difference because unless they're setting up their computer for the first time, because the windows key would already be installed. The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?)
If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
The enrolling of the certs happen before the bootloader calls `ExitBootServices()` (I think that is what the function was called). Up until then the bootloader still has elevated priviledges and can modify certain UEFI stuff it can't after, including enrolling certs.
systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2]
No, there's nothing special about the spec secure boot variables as far as boot services goes - you can modify those in runtime as well. We use boot service variables to protect the MOK key in Shim, but that's outside what the spec defines as secure boot.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
I was talking about the same "install" that is already done (pre-installed on the drive that is first booted).
Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them.
This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens.
What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack.
If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said.
UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
I have always enjoyed the experience of installing my favorite hobbyist teletype operating system. I think the last time I used a preinstalled on a personal machine was windows 3.1 on a 486.
> Crucially the end user should then be ASKED which to enable
except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO
this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.
This is what you get when a programmer designs a system.
The end user wants to be able to just pick up a computer from Best Buy and have it work, out of the box.
Microsoft can't even conceptualize why you would want to run anything but the Windows that came with the machine. If the expected Windows kernel and files aren't there, or have been altered, that is evidence of malicious tampering—malware that must be stopped. (I'm deliberately steelmanning their perspective here.)
Streaming services want a secure content path. Game vendors want protection against cheating. In order to comply with local/regional/national laws, web sites need you to verify your age, and they need to know your computer is not lying (remote attestation). Nobody wants to be hacked.
The incentives for everyone else besides techies align against techies getting to run arbitrary code on their devices. The Secure Boot system is working precisely as designed.
It is 2026, people still use cheat software on public servers. It works about as well as DRM.
> Vendors couldn't care less.
There are more than enough games that are designed around microtransactions that use grind and gambling mechanics to encourage spending. Throw bots and cheats at that and the entire thing breaks down.
The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.
Thre original secure boot design would have had insecure bootloaders get blacklisted the moment abuse could be detected.
Microsoft then made that system entirely useless by signing code that could be used to load unsigned code, like demonstrated here.
They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). That vulnerable bootloader is particularly bad because it can be used to have the TPM unlock itself and give up the Bitlocker key, which the Linux loaders shouldn'tbe capable of even if they apply the bypass mentioned in the article.
In a world where Microsoft cared about secure boot, they would blacklist the vulnerable Linux loaders as well as their own old bootloaders. Why Microsoft? Because they signed the files in the first place, only they can rescind the signatures. In that world, Linux users would call for Bill Gates' head for securing their security feature and sysadmins would be out for Steve Ballmer's blood for breaking their complex custom recovery system that nobody dares touch.
>They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader).
Source? The OP suggests they expect it to be blacklisted
>I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update
If you search around you'll also find that microsoft does publish secure boot revocations, contrary to what you claim.
They blacklist some bootloaders, but it takes them forever. CVE-2023-24932 (from May 2023) had a fix available a year later (June 2024), had the update broadly made available through standard updates in 2025 (2 years later) and doesn't automatically install it today.
You might think the 2025 update will solve the problem, but:
> Before following these steps for applying the mitigations, install the Windows monthly servicing update released on July 8, 2025, or a later update on supported Windows devices. This update includes mitigations for CVE-2023-24932 but they are not enabled by default. All Windows devices should complete this step regardless of your plan to enable the mitigations.
> The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following:
Basically, unless your company and sysadmin have enforced this fix (i.e. you're a home user), Microsoft hasn't revoked their keys.
Then there's CVE-2024-38058, a similar attack. Microsoft tried to roll out a fix, but that broke compatibility, and the fix was then rolled back. Again, that problem can be fixed with the solution for the previous CVE, but that is still not deployed by default.
A better design would not involve a small default-trusted set of keys in the first place. If the signers were diverse and on equal footing, with users choosing who to trust, a single bad bootloader being signed would not compromise nearly the whole ecosystem.
Security through obscurity is not a great idea. This is what Apple's current approach is. For instance if your iPhone is infected with malware, there is no anti-virus software that can find it, because Apple doesn't let software to have such deep access that is needed for scanning.
It's not security by obscurity. It's security by minimizing the attack service by being extremely picky about what you sign. When it is paramount that the code you sign is correct you can't go signing a ton of different projects from people who may not even care about security as much as you do.
>For instance if your iPhone is infected with malware
Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
> Apple doesn't let software to have such deep access that is needed for scanning
Normalizing "security" software running in the background to "scan" things has proven a social and technical disaster. Users think it's normal to have such activity (and receive random "virus alerts"), leading to over two decades of social engineering scams, fraud, and malware-delivery. On top of that, "security" software has a habit of creating its own security holes and problems. Look at game anti-cheats (one was just on the front page the other day), the CrowdStrike incident, etc.
OS vendors should simply deliver a secure OS. That isn't easy, but it's still easier and more reliable than shipping third-party "security" software after the fact.
The issue isn’t “normalising pop-up virus scanners” or letting random vendors hook the kernel. It’s verifiability. On Apple platforms, the security model is explicitly “trust us bro”. You cannot independently inspect the system at the level required to detect certain classes of compromise, because Apple forbids it.
A platform where compromise is, by design, undetectable to the owner is not “more secure”, it’s merely less observable. That’s security through opacity, not security through design.
Yes, third-party security software has a bad history. So does third-party everything. That doesn’t magically make a closed system safer. It just moves all trust to a single vendor, removes independent validation, and ensures that when something slips through, only the platform owner gets to decide whether it exists.
“The OS vendor should deliver a secure OS” is an aspiration, not an argument. No OS is bug-free. Defence in depth means independent mechanisms of inspection, not just a promise that the walls are high enough.
Apple’s model works well for reducing mass-market malware and user error. It does not work for high-assurance trust, because you cannot verify state. If you can’t audit, you can’t prove clean. You can only assume.
That may be a perfectly acceptable trade-off. But let’s not pretend it’s the same thing as stronger security. It’s a different philosophy, and it comes with real blind spots - which to some people make Apple devices a non-starter.
> Most motherboards include only Microsoft keys as trusted
Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile.
> Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule
> Is this really true, in 2019 when this was written or today?
This is true in the sense that they only ship with MS' keys as trusted, but all MoBos (including laptops) I had allow enrolling your own. Some might handle not having MS' keys better (or at all) than others, but it should in theory be possible to remove them, whether it will boot after is a different question (see option-ROM [1])
You are missing the point. It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs.
So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft.
Let's not forget that we're talking about the company responsible for Windows 11 here.
Of the GPLv3 sentence? No, it's dishonest rhetorically. Of the piece? Also I don't think so, exploiting the shims is a fun way to prove that Secure Boot is silly but we already knew that, and by 2019 claiming that "most" systems only allowed Microsoft keys is just flat out dishonest as well.
> It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs.
I really don't get this argument in general; Microsoft certs are enrolled by default as a combination of: a matter of convenience for majority users who are going to use Microsoft OSes, the unfortunate design of Option ROM signature checking, and the desire to get a Windows logo on the packaging and Microsoft OEM discounts.
There's no Secure Boot or UEFI related reason that boards can't come in Setup Mode with no PK, and most industrial boards do indeed come this way, since they don't need Option ROMs and customers don't want a Microsoft logo.
> So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft.
This seems like the best outcome for end-user computers which will have Windows installed to me? Users get a computer that checks that the OS it came with is valid (well, tries to, but that's a different can of worms), and still have the option to do whatever they want with it if they so desire. They can choose the Microsoft signed shim for convenient dual-booting, or erase the platform keys and own their system end to end if they wish.
> Let's not forget that we're talking about the company responsible for Windows 11 here.
I've never really understood these arguments, and it's even weirder to bring Windows 11 into it. Is the thing we're railing against here Ballmer-Borg Microsoft? Shitty Product Management Kills Products Microsoft? AI Infested Microsoft? The Venn diagram of overlap between 1990s Microsoft (genesis of UEFI), 2012 Microsoft (Secure Boot introduction), and 2025 Microsoft (Windows 11) seems likely to be... quite small.
It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed because one of Microsoft's antivirus vendor partners couldn't write secure software to save their lives.
The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
It's very easy to disable Secure Boot, or run shim which is signed by Microsoft and can explicitly boot untrusted code if setup (with local user interaction) to do so.
No, this is not true at all. Microsoft requires their system vendors (Dell, HP, etc) to allow users to enroll their own Secure Boot keys through their “Designed for Windows” certification.
Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.
> Is it possible to un-enroll the Microslop certificates
Technically yes, with a massive fucking asterisk: Some option-ROM are signed with the MS certs and if your Motherboard doesn't support not loading those (whether needed or not) you will not be able to sometimes even POST.
With almost all modern motherboard firmware you can enter Setup mode and use KeyTool to configure the trust store however you want, starting from enrolling a user PK (Platform Key) upwards.
It’s generally a lot more secure to avoid the use of any shims (since they leave you vulnerable to what happened in this article) and just build a UEFI Kernel Image and sign that.
Some systems need third party firmware to reach the OS, and this can get a bit more complicated since those modules need to load with the new user keys, but overall what you are asking is generally possible.
> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed
This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys.
The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.
I don't think it deserves quite that easy a dismissal; MS did lock down early UEFI+ARM devices and prohibit user-controlled keys (see the Windows RT devices as an example). Given their history of playing dirty, it's perfectly reasonable that people assumed this to be another play at undermining Linux, even if things didn't end up going that way.
By 2019, when the parent article was written, I don't think that was a good read on the situation. By 2026, when the parent comment was written, I really don't think it's a good read on the situation.
It's hard to believe when MS use secure boot to prevent Linux being able to boot. Twice now on my dual boot system a Windows update has prevented Linux being bootable. If it weren't for MS's history one might consider it the accident of a ridiculously inept company.
Even just the lies around required hw updates is enough not to trust them.
SecureBoot looks like a system designed to make it hard to change OS, it has been used by MS for that, MS have a history of user-antagonist actions.
You say the conspiracy was never true, I'm going to need some serious proof.
> SecureBoot looks like a system designed to make it hard to change OS
To be fair SecureBoot is in a way just that: it is intended to only boot binaries that are signed with a key that has been enrolled into the UEFI. The main issue is like almost always how those keys are managed.
> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all
SecureBoot exists on servers too. And that's the domain of Linux, not Windows.
Microsoft should never have had so much influence in SecureBoot but there's no way they're getting rid of Linux on servers. Microsoft is mostly irrelevant there.
> The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
That's also a weird take. It's antivirus vendors who are going to be fine forever: they rely on Microsoft to write crappy insecure software. And that is a given.
If you Google around, you'll find that about 1/3 of server operating systems broken down by revenue (not install count) is Windows Server. That's billions of dollars.
Empowering the 'User' (hardware owner) should have always been the focus.
From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).
> From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microslop, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot).
The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...)
> The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
Isn't this already the status quo??
> It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...]
I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.
>IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Sounds like browserchoice.eu but even more pointless. For the normies who don't care about what keys they want installed, it doesn't make a difference. For people who want to switch to linux, it also doesn't make a difference because unless they're setting up their computer for the first time, because the windows key would already be installed. The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?)
If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
The enrolling of the certs happen before the bootloader calls `ExitBootServices()` (I think that is what the function was called). Up until then the bootloader still has elevated priviledges and can modify certain UEFI stuff it can't after, including enrolling certs.
systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2]
[1]: https://www.freedesktop.org/software/systemd/man/latest/syst...
[2]: https://www.freedesktop.org/software/systemd/man/latest/load...
No, there's nothing special about the spec secure boot variables as far as boot services goes - you can modify those in runtime as well. We use boot service variables to protect the MOK key in Shim, but that's outside what the spec defines as secure boot.
> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
I was talking about the same "install" that is already done (pre-installed on the drive that is first booted).
Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them.
This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens.
See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/syst...
What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack.
If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said.
UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
I have always enjoyed the experience of installing my favorite hobbyist teletype operating system. I think the last time I used a preinstalled on a personal machine was windows 3.1 on a 486.
> Crucially the end user should then be ASKED which to enable
except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO
this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.
This is what you get when a programmer designs a system.
The end user wants to be able to just pick up a computer from Best Buy and have it work, out of the box.
Microsoft can't even conceptualize why you would want to run anything but the Windows that came with the machine. If the expected Windows kernel and files aren't there, or have been altered, that is evidence of malicious tampering—malware that must be stopped. (I'm deliberately steelmanning their perspective here.)
Streaming services want a secure content path. Game vendors want protection against cheating. In order to comply with local/regional/national laws, web sites need you to verify your age, and they need to know your computer is not lying (remote attestation). Nobody wants to be hacked.
The incentives for everyone else besides techies align against techies getting to run arbitrary code on their devices. The Secure Boot system is working precisely as designed.
> Game vendors want protection against cheating
Gamers, gamers want anti-cheats. Vendors couldn't care less.
It is 2026, people still use cheat software on public servers. It works about as well as DRM.
> Vendors couldn't care less.
There are more than enough games that are designed around microtransactions that use grind and gambling mechanics to encourage spending. Throw bots and cheats at that and the entire thing breaks down.
Gamers want no cheaters, vendors want to be seen to be trying in the cheapest way that has credibility.
(2019)
The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.
Thre original secure boot design would have had insecure bootloaders get blacklisted the moment abuse could be detected.
Microsoft then made that system entirely useless by signing code that could be used to load unsigned code, like demonstrated here.
They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). That vulnerable bootloader is particularly bad because it can be used to have the TPM unlock itself and give up the Bitlocker key, which the Linux loaders shouldn'tbe capable of even if they apply the bypass mentioned in the article.
In a world where Microsoft cared about secure boot, they would blacklist the vulnerable Linux loaders as well as their own old bootloaders. Why Microsoft? Because they signed the files in the first place, only they can rescind the signatures. In that world, Linux users would call for Bill Gates' head for securing their security feature and sysadmins would be out for Steve Ballmer's blood for breaking their complex custom recovery system that nobody dares touch.
Now we'll be stuck in the worst of both worlds.
>They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader).
Source? The OP suggests they expect it to be blacklisted
>I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update
If you search around you'll also find that microsoft does publish secure boot revocations, contrary to what you claim.
https://github.com/fwupd/dbx-firmware
They blacklist some bootloaders, but it takes them forever. CVE-2023-24932 (from May 2023) had a fix available a year later (June 2024), had the update broadly made available through standard updates in 2025 (2 years later) and doesn't automatically install it today.
You might think the 2025 update will solve the problem, but:
> Before following these steps for applying the mitigations, install the Windows monthly servicing update released on July 8, 2025, or a later update on supported Windows devices. This update includes mitigations for CVE-2023-24932 but they are not enabled by default. All Windows devices should complete this step regardless of your plan to enable the mitigations.
The current status for the update (https://support.microsoft.com/en-us/topic/how-to-manage-the-...) says:
> The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following:
Basically, unless your company and sysadmin have enforced this fix (i.e. you're a home user), Microsoft hasn't revoked their keys.
Then there's CVE-2024-38058, a similar attack. Microsoft tried to roll out a fix, but that broke compatibility, and the fix was then rolled back. Again, that problem can be fixed with the solution for the previous CVE, but that is still not deployed by default.
https://neodyme.io/en/blog/bitlocker_screwed_without_a_screw... describes the TPM2 attack in detail as well as mitigations and solutions much better than I can.
I feel like this isn’t the best moment to call Bill Gates. Or maybe yes, maybe he’ll open source Windows at this point, who knows!
A better design would not involve a small default-trusted set of keys in the first place. If the signers were diverse and on equal footing, with users choosing who to trust, a single bad bootloader being signed would not compromise nearly the whole ecosystem.
Third party? Black Lotus was the first case we saw actually targeting individuals, and that was a vulnerability in the Windows bootloader.
The security story of the PC platform is such a mess due to fragmentation. I have way more trust in Apple's security here.
Security through obscurity is not a great idea. This is what Apple's current approach is. For instance if your iPhone is infected with malware, there is no anti-virus software that can find it, because Apple doesn't let software to have such deep access that is needed for scanning.
It's not security by obscurity. It's security by minimizing the attack service by being extremely picky about what you sign. When it is paramount that the code you sign is correct you can't go signing a ton of different projects from people who may not even care about security as much as you do.
>For instance if your iPhone is infected with malware
Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
> Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
Not things like Pegasus.
It does not minimise attack surface, but minimise ways _you_ can ensure there is nothing on the phone that shouldn't be there.
> Apple doesn't let software to have such deep access that is needed for scanning
Normalizing "security" software running in the background to "scan" things has proven a social and technical disaster. Users think it's normal to have such activity (and receive random "virus alerts"), leading to over two decades of social engineering scams, fraud, and malware-delivery. On top of that, "security" software has a habit of creating its own security holes and problems. Look at game anti-cheats (one was just on the front page the other day), the CrowdStrike incident, etc.
OS vendors should simply deliver a secure OS. That isn't easy, but it's still easier and more reliable than shipping third-party "security" software after the fact.
The issue isn’t “normalising pop-up virus scanners” or letting random vendors hook the kernel. It’s verifiability. On Apple platforms, the security model is explicitly “trust us bro”. You cannot independently inspect the system at the level required to detect certain classes of compromise, because Apple forbids it.
A platform where compromise is, by design, undetectable to the owner is not “more secure”, it’s merely less observable. That’s security through opacity, not security through design.
Yes, third-party security software has a bad history. So does third-party everything. That doesn’t magically make a closed system safer. It just moves all trust to a single vendor, removes independent validation, and ensures that when something slips through, only the platform owner gets to decide whether it exists.
“The OS vendor should deliver a secure OS” is an aspiration, not an argument. No OS is bug-free. Defence in depth means independent mechanisms of inspection, not just a promise that the walls are high enough.
Apple’s model works well for reducing mass-market malware and user error. It does not work for high-assurance trust, because you cannot verify state. If you can’t audit, you can’t prove clean. You can only assume.
That may be a perfectly acceptable trade-off. But let’s not pretend it’s the same thing as stronger security. It’s a different philosophy, and it comes with real blind spots - which to some people make Apple devices a non-starter.
> Most motherboards include only Microsoft keys as trusted
Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile.
> Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule
Ah yes, GPLv3 is now Microsoft’s fault?
> Is this really true, in 2019 when this was written or today?
This is true in the sense that they only ship with MS' keys as trusted, but all MoBos (including laptops) I had allow enrolling your own. Some might handle not having MS' keys better (or at all) than others, but it should in theory be possible to remove them, whether it will boot after is a different question (see option-ROM [1])
[1]: https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
>Ah yes, GPLv3 is now Microsoft’s fault?
You are missing the point. It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs.
So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft.
Let's not forget that we're talking about the company responsible for Windows 11 here.
> You are missing the point
Of the GPLv3 sentence? No, it's dishonest rhetorically. Of the piece? Also I don't think so, exploiting the shims is a fun way to prove that Secure Boot is silly but we already knew that, and by 2019 claiming that "most" systems only allowed Microsoft keys is just flat out dishonest as well.
> It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs.
I really don't get this argument in general; Microsoft certs are enrolled by default as a combination of: a matter of convenience for majority users who are going to use Microsoft OSes, the unfortunate design of Option ROM signature checking, and the desire to get a Windows logo on the packaging and Microsoft OEM discounts.
There's no Secure Boot or UEFI related reason that boards can't come in Setup Mode with no PK, and most industrial boards do indeed come this way, since they don't need Option ROMs and customers don't want a Microsoft logo.
> So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft.
This seems like the best outcome for end-user computers which will have Windows installed to me? Users get a computer that checks that the OS it came with is valid (well, tries to, but that's a different can of worms), and still have the option to do whatever they want with it if they so desire. They can choose the Microsoft signed shim for convenient dual-booting, or erase the platform keys and own their system end to end if they wish.
> Let's not forget that we're talking about the company responsible for Windows 11 here.
I've never really understood these arguments, and it's even weirder to bring Windows 11 into it. Is the thing we're railing against here Ballmer-Borg Microsoft? Shitty Product Management Kills Products Microsoft? AI Infested Microsoft? The Venn diagram of overlap between 1990s Microsoft (genesis of UEFI), 2012 Microsoft (Secure Boot introduction), and 2025 Microsoft (Windows 11) seems likely to be... quite small.
It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed because one of Microsoft's antivirus vendor partners couldn't write secure software to save their lives.
The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
It's very easy to disable Secure Boot, or run shim which is signed by Microsoft and can explicitly boot untrusted code if setup (with local user interaction) to do so.
No, this is not true at all. Microsoft requires their system vendors (Dell, HP, etc) to allow users to enroll their own Secure Boot keys through their “Designed for Windows” certification.
Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.
Is it possible to un-enroll the Microsoft certificates, and just trust the efi shim?
> Is it possible to un-enroll the Microslop certificates
Technically yes, with a massive fucking asterisk: Some option-ROM are signed with the MS certs and if your Motherboard doesn't support not loading those (whether needed or not) you will not be able to sometimes even POST.
https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom
With almost all modern motherboard firmware you can enter Setup mode and use KeyTool to configure the trust store however you want, starting from enrolling a user PK (Platform Key) upwards.
It’s generally a lot more secure to avoid the use of any shims (since they leave you vulnerable to what happened in this article) and just build a UEFI Kernel Image and sign that.
Some systems need third party firmware to reach the OS, and this can get a bit more complicated since those modules need to load with the new user keys, but overall what you are asking is generally possible.
> just build a UEFI Kernel Image and sign that.
examples and documentation welcome
https://wiki.archlinux.org/title/Unified_kernel_image#ukify_...
https://wiki.gentoo.org/wiki/Secure_Boot
> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all failed
This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys.
The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.
I don't think it deserves quite that easy a dismissal; MS did lock down early UEFI+ARM devices and prohibit user-controlled keys (see the Windows RT devices as an example). Given their history of playing dirty, it's perfectly reasonable that people assumed this to be another play at undermining Linux, even if things didn't end up going that way.
By 2019, when the parent article was written, I don't think that was a good read on the situation. By 2026, when the parent comment was written, I really don't think it's a good read on the situation.
It's hard to believe when MS use secure boot to prevent Linux being able to boot. Twice now on my dual boot system a Windows update has prevented Linux being bootable. If it weren't for MS's history one might consider it the accident of a ridiculously inept company.
Even just the lies around required hw updates is enough not to trust them.
SecureBoot looks like a system designed to make it hard to change OS, it has been used by MS for that, MS have a history of user-antagonist actions.
You say the conspiracy was never true, I'm going to need some serious proof.
> SecureBoot looks like a system designed to make it hard to change OS
To be fair SecureBoot is in a way just that: it is intended to only boot binaries that are signed with a key that has been enrolled into the UEFI. The main issue is like almost always how those keys are managed.
> It's really funny to me that Microsoft's attempt to finally stamp out desktop Linux once and for all
SecureBoot exists on servers too. And that's the domain of Linux, not Windows.
Microsoft should never have had so much influence in SecureBoot but there's no way they're getting rid of Linux on servers. Microsoft is mostly irrelevant there.
> The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
That's also a weird take. It's antivirus vendors who are going to be fine forever: they rely on Microsoft to write crappy insecure software. And that is a given.
If you Google around, you'll find that about 1/3 of server operating systems broken down by revenue (not install count) is Windows Server. That's billions of dollars.