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.
You are missing the big picture.
> 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.
On the contrary. It means only the currently installed OS will ever boot. If you wanted to switch you would enter the bios, clear the keys, then boot into the new system. That's roughly analogous to re-locking the bootloader on a pixel.
Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
>Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
There will still be the situation with microsoft signing third party bootloaders, because various legitimate system utilities (eg. the kaspersky rescue disk mentioned in the OP) will still need it, and telling users to clear their keys willy-nilly is just going to train users to blindly clear their keys whenever something goes wrong.
> 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.
This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot?
PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you.
To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine.
> No one said anything about a nag screen.
The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today.
> For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader
So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
And how many times has Intel's trusted computing platform been breached now? Would you also claim that SGX is not a meaningful security measure? Recall that the alternative to SecureBoot is ... oh that's right, there isn't an equivalent alternative.
People have broken into bank vaults. That doesn't mean that bank vaults don't provide meaningful security.
> So do UEFI systems. Install OS, test boot, enroll PK.
"Enroll PK" is "draw the rest of the fucking owl" territory.
I believe you somewhat misunderstood OP. The description was of the empty hardware. Typical hardware would ship with an OS already installed and marked as trusted. It's the flow for changing the OS that would be different.
> automatically enroll the first key it sees from disk (supply chain issue, like I posted)
I'm unconvinced. You're supposing an attacker that can compromise an OEM's imaging solution but not the (user configurable!) key store? That seems like an overly specific attack vector to me.
The breach in TFA happened because Microsoft actually did something benevolent and it blew up on their face. Now almost all of the hardware that takes security a bit seriously (basically expensive business class computers) have to upgrade their UEFI FW (many have already done ao via Windows Update).
No single point of failure will protect you fully. UEFI SB is just one layer. And nobody ever would protect you from a dedicated nation state (except another nation state). Unless you own the entire supply chain from silicon contractors all the way up to every single software vendor and every single network operator, you cannot fully prove things aren't snitching on you.
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.
> 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.
> 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.
"Your right to swing your arms ends just where the other man’s nose begins."
Every time I see someone campaigning to exercise their civil liberties via hardware or software, I wonder if their devices are connected to any network.
Because once you connect to a network, especially a WAN, your liberties are tempered by the rights of all other users.
If your device hosts malware, botnets, scammers, spammers, or other malicious activity, no you do not have a right to the liberty of your hardware. The network and the service providers have a fiduciary responsibility of harm reduction and threat mitigation.
Sure, some hackers are very very good at preventing malware and keeping the botnets at bay. You may be better at it than cloud providers or your ISP. In fact, it is the inexperienced users that we can't really trust. They'll get pwned and their browser will have a million toolbars with spyware. Their PC will join botnets and host CSAM. It is their ignorance and ineptitude that gets them into trouble.
And so because WANs, particularly the public Internet, are common property, and not your private domain or sandbox, this is why things like device trust and attestation are being added. Because you could do all you wanted with your Commodore 64 and your Apple ][. The blast radius was limited to your family and every friend who traded cracked software.
But once you're hooked up on a network, you need to stop swinging your fists at my nose.
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.
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.
>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.
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.
> 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.
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.
We're talking about the verification of the boot chain, and last I heard, Pegasus has never subverted that: its strategy is to break back in after every reboot.
Not really, airlines do the same thing. Cockpit security protects you against hijackings from any of the 200-odd crazies in the cabin, but not the 3-4 "trusted" individuals in the cockpit.
The way things are headed, it's getting hard to trust the people in Apple's metaphorical cockpit.
> 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.
..was totally expecting this article to be written in Chinese, because it is an active attack vector being used to infiltrate western IT infrastructure by pre-loading spyware into the boot loaders, then clicked the article and the link opened to Cyrillic characters. Of course, APT29 is doing this too, but their agents aren't thought to be in the supply chain, so they have to infect the products after installation (using traditional hacking techniques). Look at how Intel ME and AMD PSP work and presume that something similar is in the latest Allwinner, Rockchip, Alibaba, and Nuclei, etc.. chips. To the Chinese, this seems fair because "the other Party" is doing it. Not arguing that it isn't, just that most customers have their head in the sand denying it is happening (even using them in IPKVMs!)
There was also a Western paper on embedding hidden circuits (and thus functionality/ISAs) into CPUs and activating them in the field (after deployment) by executing a sequence of opcodes resulting in something akin to blowing a fuse on the processor die, thereby making the circuits invisible (to even a microscope) until activated. Those secret opcodes could then disable the chip or jump into a block of secret microcode and alter the program counter to behave in a non-standard manner so we might not easily be able to see what's happening, even if we knew to look. One still would have to deliver that secret sequence of opcodes to trigger such a stealth mode...that could be done via microcode/firmware updates from the manufacturer's website or an OS update, or similar techniques. Interestingly, an unexpected iteration of Chinese SoCs began flooding the markets just as the rest of the World was sustaining a "chip shortage" in a timeframe perfectly aligned with what would have been required to implement such a system after that paper was published.
Air-gapping the customer's devices during installation (to prevent the activation opcode sequence) might not work either. Many Chinese SoCs are used as embedded peripherals simply to add WiFi, Bluetooth and Thread capabilities onto existing designs via a simple UART or doorbell interconnect. This makes it too easy for these Chinese SoCs to also be listening for a Morse-code-like activation signal on a low-frequency band, triggering the backdoor to open (enabling a more conventional remote code execution port or logic debugger exposed via WiFi or BLE for example, or causing malfunction or damage to what's on the GPIO or UART pins). Such low-frequencies could be disguised (think Blue Whale signals) so they might be sent slowly over great distances (or even from floating weather balloons or low earth orbit) without drawing too much suspicion. https://youtu.be/E-gbYjLd93g
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 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.
If you buy cheap HW you'll get totally half-assed firmware. It is usually the firmware that causes stupid reordering of the boot entries and weird resets.
Business class computers (Thinkpads, Latitudes or Elitebooks) have somewhat half-assed firmware. So you usually don't encounter shenanigans like that.
Only server computers have almost not half-assed firmware. They are very reliable but take forever to boot.
If you want non-half-assed firmware, found your own computer company or join big tech where they can afford custom motherboards with their own firmware.
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
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.
You are missing the big picture. > 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.
this is much more important than you realize.
Why? Of all the barriers to "year of the linux desktop", this isn't really one of them, especially with shim loader.
On the contrary. It means only the currently installed OS will ever boot. If you wanted to switch you would enter the bios, clear the keys, then boot into the new system. That's roughly analogous to re-locking the bootloader on a pixel.
Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
>Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
There will still be the situation with microsoft signing third party bootloaders, because various legitimate system utilities (eg. the kaspersky rescue disk mentioned in the OP) will still need it, and telling users to clear their keys willy-nilly is just going to train users to blindly clear their keys whenever something goes wrong.
> 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.
> UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level
Baseless FUD. If you have an actual point to make then do so.
> All of these "add more nag screens for freedom"
No one said anything about a nag screen. You literally just made that up.
For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader.
> Baseless FUD.
This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot?
PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you.
To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine.
> No one said anything about a nag screen.
The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today.
> For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader
So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
And how many times has Intel's trusted computing platform been breached now? Would you also claim that SGX is not a meaningful security measure? Recall that the alternative to SecureBoot is ... oh that's right, there isn't an equivalent alternative.
People have broken into bank vaults. That doesn't mean that bank vaults don't provide meaningful security.
> So do UEFI systems. Install OS, test boot, enroll PK.
"Enroll PK" is "draw the rest of the fucking owl" territory.
I believe you somewhat misunderstood OP. The description was of the empty hardware. Typical hardware would ship with an OS already installed and marked as trusted. It's the flow for changing the OS that would be different.
> automatically enroll the first key it sees from disk (supply chain issue, like I posted)
I'm unconvinced. You're supposing an attacker that can compromise an OEM's imaging solution but not the (user configurable!) key store? That seems like an overly specific attack vector to me.
The breach in TFA happened because Microsoft actually did something benevolent and it blew up on their face. Now almost all of the hardware that takes security a bit seriously (basically expensive business class computers) have to upgrade their UEFI FW (many have already done ao via Windows Update).
No single point of failure will protect you fully. UEFI SB is just one layer. And nobody ever would protect you from a dedicated nation state (except another nation state). Unless you own the entire supply chain from silicon contractors all the way up to every single software vendor and every single network operator, you cannot fully prove things aren't snitching on you.
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.
> 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.
> Crucially the end user should then be ASKED which to enable
This doesn't work for literally 99.9% of the users out there. This is a classic HN's Dropbox symptom.
You need overridable defaults.
> Empowering the 'User' (hardware owner) should have always been the focus.
The "user" and "hardware owner" are not necessarily the same person.
> 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.
In companies the user is often not the actual owner of hardware.
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.
"Your right to swing your arms ends just where the other man’s nose begins."
Every time I see someone campaigning to exercise their civil liberties via hardware or software, I wonder if their devices are connected to any network.
Because once you connect to a network, especially a WAN, your liberties are tempered by the rights of all other users.
If your device hosts malware, botnets, scammers, spammers, or other malicious activity, no you do not have a right to the liberty of your hardware. The network and the service providers have a fiduciary responsibility of harm reduction and threat mitigation.
Sure, some hackers are very very good at preventing malware and keeping the botnets at bay. You may be better at it than cloud providers or your ISP. In fact, it is the inexperienced users that we can't really trust. They'll get pwned and their browser will have a million toolbars with spyware. Their PC will join botnets and host CSAM. It is their ignorance and ineptitude that gets them into trouble.
And so because WANs, particularly the public Internet, are common property, and not your private domain or sandbox, this is why things like device trust and attestation are being added. Because you could do all you wanted with your Commodore 64 and your Apple ][. The blast radius was limited to your family and every friend who traded cracked software.
But once you're hooked up on a network, you need to stop swinging your fists at my nose.
(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.
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.
>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!
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.
Ditto hardware designed by Google.
Google's hardware is great, GrapheneOS et. al will attest. It's the software that stinks, just like iPhone.
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.
> 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.
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.
We're talking about the verification of the boot chain, and last I heard, Pegasus has never subverted that: its strategy is to break back in after every reboot.
Well, you won't know the details because Apple keeps them to themselves and you won't be able to verify it. So that is pointless.
That is a perverse use of "security through obscurity".
Not really, airlines do the same thing. Cockpit security protects you against hijackings from any of the 200-odd crazies in the cabin, but not the 3-4 "trusted" individuals in the cockpit.
The way things are headed, it's getting hard to trust the people in Apple's metaphorical cockpit.
And this, kids, is why you roll your own EFI keys.
> 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.
My last Gigabyte bios update decided to automatically enable secure boot without asking...
No that it bothers me all that much either way.
> 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.
..was totally expecting this article to be written in Chinese, because it is an active attack vector being used to infiltrate western IT infrastructure by pre-loading spyware into the boot loaders, then clicked the article and the link opened to Cyrillic characters. Of course, APT29 is doing this too, but their agents aren't thought to be in the supply chain, so they have to infect the products after installation (using traditional hacking techniques). Look at how Intel ME and AMD PSP work and presume that something similar is in the latest Allwinner, Rockchip, Alibaba, and Nuclei, etc.. chips. To the Chinese, this seems fair because "the other Party" is doing it. Not arguing that it isn't, just that most customers have their head in the sand denying it is happening (even using them in IPKVMs!)
There was also a Western paper on embedding hidden circuits (and thus functionality/ISAs) into CPUs and activating them in the field (after deployment) by executing a sequence of opcodes resulting in something akin to blowing a fuse on the processor die, thereby making the circuits invisible (to even a microscope) until activated. Those secret opcodes could then disable the chip or jump into a block of secret microcode and alter the program counter to behave in a non-standard manner so we might not easily be able to see what's happening, even if we knew to look. One still would have to deliver that secret sequence of opcodes to trigger such a stealth mode...that could be done via microcode/firmware updates from the manufacturer's website or an OS update, or similar techniques. Interestingly, an unexpected iteration of Chinese SoCs began flooding the markets just as the rest of the World was sustaining a "chip shortage" in a timeframe perfectly aligned with what would have been required to implement such a system after that paper was published.
Air-gapping the customer's devices during installation (to prevent the activation opcode sequence) might not work either. Many Chinese SoCs are used as embedded peripherals simply to add WiFi, Bluetooth and Thread capabilities onto existing designs via a simple UART or doorbell interconnect. This makes it too easy for these Chinese SoCs to also be listening for a Morse-code-like activation signal on a low-frequency band, triggering the backdoor to open (enabling a more conventional remote code execution port or logic debugger exposed via WiFi or BLE for example, or causing malfunction or damage to what's on the GPIO or UART pins). Such low-frequencies could be disguised (think Blue Whale signals) so they might be sent slowly over great distances (or even from floating weather balloons or low earth orbit) without drawing too much suspicion. https://youtu.be/E-gbYjLd93g
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.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.
I think that they definitely wanted to iOSify Windows but the colossal failure of Windows 8 and Windows RT led them to take a different approach.
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.
If you buy cheap HW you'll get totally half-assed firmware. It is usually the firmware that causes stupid reordering of the boot entries and weird resets.
Business class computers (Thinkpads, Latitudes or Elitebooks) have somewhat half-assed firmware. So you usually don't encounter shenanigans like that.
Only server computers have almost not half-assed firmware. They are very reliable but take forever to boot.
If you want non-half-assed firmware, found your own computer company or join big tech where they can afford custom motherboards with their own firmware.
Of course, Microsoft has always loved Linux and we have always been at war with Eurasia.
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
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.
What portion of BigCo use RHEL or other paid solutions vs using a standard distro and thus not counting as “revenue” for anyone?