The OP is careful and measured. This comment is the opposite.
Well, sorry, but no. I will sound the alarm way before the only way to install Linux (or any other OS) is to disassemble the laptop and hit some physical switch that will cause a Scary Boot Prompt to be permanently shown on my device, reminding me that I'm booting an "unsupported OS" and that "someone could be doing this to steal my personal data", and requiring me to acknowledge it by waiting 30 seconds before it proceeds to boot my actual OS. Every Single Time I boot the device. I will complain loudly way before we reach that on PCs.
Cause that's exactly what I had to do to run Linux on a Chromebook. And Google also seems to think that because they allow me to run some Linux distros under a heavily curtained container inside their OS, "all's good". Google does not get a free pass from me, why should MS?
Once people start side-loading to get around future bans on E2EE messaging apps, I expect governments will require OS vendors to implement blacklisting of such software even on desktops, using something like Apple's Gatekeeper service[1].
[0] https://www.pcgamesn.com/valorant/windows-11
[1] https://appleinsider.com/articles/20/11/15/big-sur-telling-a...
Fair disclosure, I've been involved in products supporting secure boot, have run my own laptop with my own keys such that only my signed stuff runs. I also have one of those Talos 2 boards and it also supports its own secure boot, even though all of the software all the way down to the firmware is open source.
So far Microsoft have actually been pretty reasonable: they enabled the shim in the first place. No Linux distros including heavyweights like Redhat or Canonical stepped up to undergo the requirements for default inclusion in the UEFI forum.
It always strikes me as a logical fallacy to argue against having a secure boot but then be pro end to end encryption. 'Secure boot is being used to oppress us therefore secure boot is bad' is as extreme a view as 'some awful human beings share csam so end-to-end bad'.
Ultimately in both cases the problem is societal and not technical. We need consumer rights protections so we don't end up renting our devices, and we need policing and community work to eradicate csam. Frothing at the mouth misinformed 'activism' comes across very badly to people outside the tech world we necessarily need to engage to make constructive policies for the future.
> There's separate issues at play: the mechanism, what value it adds or subtracts and how it can be used.
The thing is, it's absurd to separate these issues. Look at it from the perspective of most users: Secure Boot is a solution to a minuscule problem. The vast majority of exploits happen in their browsers, office suits or due to social engineering (phishing, ransomware, adware).
So from the start, to sway the trade-off in favor to Secure Boot, the trouble it generates must be minuscule as well. And that is not the case: From the beginning Secure Boot has been a threat to free OS choice on PCs. Microsoft did not start by proposing a non-profit steward that will find good rules how code signing can be implemented and what rules you have to follow to be let in. That would have been "pretty reasonable". Instead they declared themselves rulers and it required a massive effort of the free software community to find ways to fulfill the requirements Microsoft unilaterally declared.
Being able to find a working process with Microsoft has generated some fragile trust, but all of that is in peril with news like Lenovo removing the Microsoft Corporation UEFI CA from their default installation.
If you would really care about letting the mechanism stand on its own without it being intermingled with politics (and I read that you care about that from the cited line) there is only one solution: Take the private keys to the Secure Boot certificates away from Microsoft and hand them over to neutral party. (And of course that will not happen, and thus the political and technical side remain deeply intertwined.)
It's a minuscule problem right now because of SB. Why spend time and effort if it's likely you'll encounter a protected system.
If you give adversaries the possibility of implanting something deep into the boot chain, you've lost the entire battle. Obviously things that get exposed to untrusted content get exploited first, but no good attacker would leave it at that, especially if they want to create persistent malware and botnets. Exactly due to *Secure Boot* we aren't suffering from mass-spread malware like the ones that existed.
> massive effort of the free software community to find ways to fulfill the requirements Microsoft unilaterally declared.
Not really massive, mostly like absolute bare minimum, if you've read them. But okay.
> Take the private keys to the Secure Boot certificates away from Microsoft and hand them over to neutral party. (And of course that will not happen, and thus the political and technical side remain deeply intertwined.)
We could totally have a third root CA as well, if mandated or needed, but I haven't heard anyone pushing for it. Apple doesn't care and most Linux distros barely support existing Secure Boot which requires much less effort than running your own CA does.
It was a minuscule problem even before SB and even today still is without SB. For most people who are exploited up to the point were malware _can write directly to the boot hard disk_, "boot chain safety" is at that point the least of the user's problems. Their data is already uploaded to a Russian server, ransomware installed, their webcam turns on without the warning LED, and all their OS security including the root account has been compromised up to the point that the attacker can start erasing off-site backups without the owner even noticing (no need and no point to compromise the boot chain).
The only scenarios were boot chain integrity would apply are evil maid scenarios where the attacker can write to the boot disk externally, i.e. _not from the user's OS itself_, and these are way outside the worries of the immense majority of users. Correctly, IMHO.
> Not really massive, mostly like absolute bare minimum [effort], if you've read them. But okay.
> most Linux distros barely support existing Secure Boot which requires much less effort than running your own CA does.
This is a just cheap criticism (even insulting) without even providing any reasoning whatsoever. And I say that as someone who has criticized Linux distributions from trying to play under the arbitrary MS rules.
Most if not all Linux distros do their own CA already. They sign packages, after all.
This is just a cheap way to handwave the problem away without even providing any reasoning whatsoever.
It wouldn't be this minuscule if that attack venue wouldn't have been made so much less worthwhile. We have real life examples of these types of attacks, how are you seriously trying to claim that it wouldn't have gotten widespread? In what universe would malware makers agree not to abuse something so high-reward if allowed?
> For most people who are exploited up to the point were malware _can write directly to the boot hard disk_, "boot chain safety" is at that point the least of the user's problems.
It's not that absolute. It's certainly bad when things have gotten that far, but it doesn't mean it isn't a good idea to protect against deeper infection. "Oh they got infected, let's just abandon it all" is just so overly reductionist and is really of no substance.
> The only scenarios were boot chain integrity would apply are evil maid scenarios where the attacker can write to the boot disk externally
Blatantly false.
> This is a just cheap criticism without even providing any reasoning whatsoever.
It's not a criticism even, it's an astute observation.
> Most if not all Linux distros do their own CA already. They sign packages, after all.
That's an even worse look for them, then, bunch of those distributions not shipping at least a signed shim (MOK enrollment excluded for now) and a signed installer.
For now I'll also skip over the fact that your average distro's package signing is way below the standards a trusted commercial CA has to follow.
> Instead they declared themselves rulers
This statement logically suggests that Microsoft laid down the law on secure boot and the impetus was entirely theirs and nobody could have done anything differently.
The UEFI forum was made into a public forum for the public version for x86. Before that it was a proprietary boot protocol designed by Intel mostly for itanium but also licensed to Apple for x86 (2010 era Mac minis use efi). Microsoft were not the originators, although I've no doubt they're contributors to this and secure boot.
Where Microsoft _do_ dictate is the Windows logo program, which is distinct from UEFI. This was the discussion originally on Matthew Garrett's blog: will they or won't they leave an 'off' option (practically they had to, to boot older windows and rescue disks).
Furthermore Microsoft's Windows logo requirements, while requiring OEMs to carry their keys on the basis OEMs want Windows logo, didn't exclude the likes of Redhat or Canonical from standing up a CA and getting included. There's some discussion of this on Matthew's older blog posts: https://mjg59.dreamwidth.org/6503.html?thread=194919 although I think there was a better discussion on OEM inclusion I can't find.
In other words we find ourselves where we are because everyone has been content for years to simply use the shim signed by Microsoft. Only Microsoft stood up a CA and underwent the due diligence. And you can't say a free CA can't be stood up, because letsencrypt went from zero to cab root programmes in this time.
The only issue in here that needs some care is forcing vendors to ship all approved CAs, not a minimum selection they care about.
Bootkits are a minor issue now as othe commentators have insinuated because of secure boot.
There are other advantages, too. With secure boot and tpms remote attestation of some systems at least becomes a bit more reasonable. You can also have the same bootkit resistance under Linux if you're prepared to put in a little bit of effort.
Sure if I had my way we'd have prioritized MTE/PAC over secure boot but there you are.
So let me sum up. Yes, what Lenovo is doing is bad, and if Microsoft are really proposing ditching third party signing then they deserve another massive antitrust suit. Looks like Matthew is again pretty much the only voice in the Linux world trying to make something practical work.
I am saying that it should always be the case that you can disable secure boot and it should always be the case that you can manage your platform keys. I also think they should ship the UEFI CA by default and offer the option to opt in to secure core as part of Windows' OOBE if they feel so compelled.
But there is a non profit neutral third party already and no Linux distro (or the Linux foundation) have pushed for CA inclusion that I know of.
UEFI and Secure Boot are here to stay unfortunately. That's not going to change (and that's more of a comment on the design of UEFI than SB).