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.
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.gentoo.org/wiki/Secure_Boot
https://wiki.archlinux.org/title/Unified_kernel_image#ukify_...
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.
> 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.