It makes more sense if you view it for what it is: Honest Satya's Certificate Authority.
Microsoft showed they can semi-competently run a PKI. The end.
Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.
"My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards.
"My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartphone, gaming console, car, and even some PCs.
"Trusted Computing" is, and always was, about making sure that the user doesn't actually own his device. This is the real, tangible attack vector - and the target of this attack is user freedom and choice.
Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?
> vendor-selected boot certificates that can't be changed
That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA certs from your device, HTTPS sites will stop working. However, nothing is stopping you from adding your own keys to the system and signing your own software with it.
> happens with every other smartphone, gaming console, car, and even some PCs
How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
> the target of this attack is user freedom and choice.
Which is exactly why users have the freedom and choice to just disable Secure Boot?
Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck.
The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut.
Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time.
What's happening in smartphone space is enough of a reason to treat Secure Boot on PC like an ongoing attack. The only reason why there are still legitimate ways to disable or adjust it is that most PC manufacturers don't have their own app store.
Freedom vs safety should be contextual. I’m not free if I don’t have choices and secure boot is a choice. Having it improves both my freedom and security somewhat. I want both unlocked and locked hardware, for different purposes.
Now do that on your smartphone. And then on your smart watch. And then on your gaming console.
Secure Boot being "a choice" on PC is an exception, not the norm. On just about every other device, the vendor is going to take a boot, shove it up your ass, and say "it's there to make your ass more secure" if you complain.
> most PC manufacturers don't have their own app store.
I feel like you misunderstand what Secure Boot does. It has absolutely nothing to do with userspace apps or app sideloading. It's true that you can't easily sideload apps on Apple devices - but that has absolutely nothing to do with Secure Boot, neither do userspace apps have anything to do with it on any other device.
At least half the reason I have a Gemini server running (the protocol, not the LLM), but no web sever anymore, is that it uses Trust On First Use, like SSH, rather than requiring all the complexities of CAs.
Not saying all of the web should switch to that while keeping everything else the same, but in some contexts it is just nice to use something simpler, as long as the risks are known to users.
> How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
The only reason there isn't a thriving community of third party OS's on most smartphones is because secure boot prevents it. And no, users do not have the freedom and choice to disable it (except on a very few models where the manufacturer has graciously allowed users to use their own devices how they want).
<< Which is exactly why users have the freedom and choice to just disable Secure Boot?
I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option.
<< How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
Does it matter? Is it mine? If yes, then it should my concern. But that is the entire problem with trusted computing and recent trends in general. Corps become operators, users are downgraded to consumers.
> I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option.
That, and fear of antitrust enforcement. The only reason we're still allowed to disable secure boot, or enroll our own keys, is that alternative PC operating systems already existed and were popular enough, that attempting to restrict PCs to only run Microsoft-approved operating systems would raise serious antitrust concerns.
But we're still at a serious risk. Microsoft still has enough influence over PC manufacturers to dictate their hardware requirements, and it would only take them being less afraid of antitrust to require them to no longer allow an override. They are already making things harder with "Secured-core PCs" (https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure...).
“ . But not only were they illegal, like debuggers—you could not install one if you had one, without knowing your computer's root password. And neither the FBI nor Microsoft Support would tell you that.”
That’s what trusted boot is, as predicted in 1997. It will come eventually.
> Which is exactly why users have the freedom and choice to just disable Secure Boot?
There's some x86 hardware in the wild where the option to disable Secure Boot does not work. Which is part of the reason why Shim exists in the first place - it allows you to boot unsigned code with the machine owner's consent, even with Secure Boot enabled.
I had a Windows 8 laptop like this. Not only that, it rejected Shim too. Never managed to install Linux on it.
Weirdly I had to leave secure boot option turned off too after a while, because more and more games started to have issues with the nVidia GPU. There was a RPG I forgot the name, isometricish that would outright crash if secure boot was turned on.
> Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?
Can someone give a _rational_ reason about why Google, Microsoft, Let's encrypt, Go lDaddy, Cloudfare etc. shall be "trusted" as opposed to "Achmed used cars and certificates" ?
I think it is only required on x86 EFI machines due to some old antitrust rulings. Provided the firmware vendor actually implements it right.
On ARM for example the hardware, including some hardware shipping with ARM version of Windows, does not need to provide the option to add custom certs and remove existing ones, so AFAIK in most cases it is not possible.
> I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.
If it's FLOSS wirh reproducible builds, your trust can be minimized, since the community verification is going on constantly. Also, your suggestion is quite inconvenient and cumbersome to use and set up.
With Heads, the firmware measures itself and sends the results to the TPM. If an attacker flashes a modified firmware that simply lies about the measurement results, the entire security system will be bypassed.
that's still secure boot, isn't it? just not uefi but homegrown?
fine with me. I read GP as rejecting the whole idea.
to point at another elephant in the room: at some point I came to realize that the ME is a x468 running some BSD. that little bitch has full access to your machine.
if trust and security is the objective, we're in for a hard ride to find trustworthy hardware.
Trusted Computing is to trust the NSA with your computing. They need to have access, right? And since they cannot control all hardware vendors, they opted to control Microsoft instead, and forced UNIX to play ball.
Call me childish, but I don’t want to ask Microsoft to sign a certificate for me before I install software onto my own hardware.
I don’t care if it’s required for every installation of if it’s once per hardware. I want to install software without asking a third party for permission. I want this to be doable entirely offline.
Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
Yeah that's how my systems are set up. I also appreciate that each firmware let's me restore the original keys just in case without me having to manually back them up -- but they're not active for secure boot.
Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.
Can easily imagine companies like Dell selling you a system with Ubuntu preinstalled but without Windows signing keys so you can't run Windows on an Ubuntu laptop (or vice-versa) with Secure Boot on an unmodified system.
Not out of malice, necessarily, but at least incompetence.
Likewise, having Microsoft signing the shim also means that any Linux installation with the signed shim can install on any system that supports Windows, whereas if RedHat had their own 100% comptent, rock-star PKI then a huge proportion of systems sold today would not be able to run Linux unmodified because the manufacturers wouldn't bother.
MS uses three separate CA's to sign Windows boot loaders, third party bootloaders (including Linux bootloaders) and UEFI Option ROMs.
In theory, no manufacturer has to install all three as trusted. But it makes no business sense to do so - why have two separate hardware SKUs for the sole purpose of lock-in? Once word got out no one would buy from that manufacturer.
Sure they would, if it would make them a buck. Lenovo for example already has separate models for pro ThinkPads with 'certified' Linux support versus the consumer line. Dell too. PC vendors already have 9000 SKUs, what's a few more?
Reminds me back in the day some vendors of Win 9x systems put something in the BIOS to prevent one from installing NT/2000. Gotta get the corporate model for that.
If Linux users had "stepped up to the plate" and demanded their own separate PKI, nothing would be different, except that every system that shipped with Windows would be locked to Windows. Dual booting would not be a thing.
I mean, your statement is self contradictory. Linux users demanded no signing etc. So, had the industry listened to Linux users, there would be no signing. We do not live in that universe.
There are some vendors that don't have secureboot. They are e.g. System76. You can enable your own SecureBoot if you want[1], though some things may not work, like checking GPU firmware signatures, because they are signed by Microsoft only (there are other issues, depending on how deeply Microsoft is assumed in your system, see e.g
"On some devices, removing either of these keys could disable all video output.")
orrr we just have official institutions which do this and enforce vendors to add certificates from other trusted parties. not only microsoft is able to do this. also microsoft already also had fallout regarding signing.
and secure boot is still the antichrist, but we have to live with them.
The problem here isn't that Microsoft is the one signing the shim, but that we can't trust systems manufacturers to update their systems, or even to have systems that can be correctly updated.
A public signing institution (or at least, a not-for-profit one) would be a great idea, but it wouldn't solve the core issue that we're worried about.
Microsoft showed they can semi-competently run a PKI. The end.
Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.