@freakazoid The bigger problem is that manufacturers cannot actually be trusted to do this right and so implementations constantly get broken, regardless of what the cryptographic model is on paper

@joepie91 Very very true. Modern computers are so complex that they're impossible to actually make secure. And every time people get harmed by some vulnerability the vendors responsible just throw up their hands and say "whoops my bad" and everyone just goes back about their business.

@freakazoid While complexity is a real issue, I think the problem is of a different nature here: bootloader security should not have been the firmware's job to begin with, this is something that is IMO handled much better on an OS level, which can finely control which things can or cannot mess with the boot setup.

@joepie91 But the OS needs to be able to ensure that nothing is running between it and the hardware, otherwise there's nothing the OS can do to keep the data secure.

@freakazoid Does it, though? What is the actual threat model here? Because this whole boot security panic started with BIOS malware - which needs to get installed somehow, which is usually going to be done by something run *within the OS*. If the OS does not permit that, nothing *can* get between the two.

The only threat models that firmware-level protections actually protect against are those that involve someone with physical access - and even then if the whole thing is configured in a watertight way and there's zero vulnerabilities in the system, and absolutely nothing except for a specific boot image is allowed to boot.

That leaves us with roughly three categories of beneficiaries:
- Particularly tech-savvy high-profile activists,
- Corporations trying to keep out employees, and
- Manufacturers trying to implement DRM.

There are other categories of people who would benefit from protection against physical attacks (folks with abusive partners, for example), but they are vanishingly unlikely to be able to set up boot security in such a way that it actually *would* protect them. And the vast majority of people are not high-profile activists.

So who is this firmware-level protection actually *for*?

@joepie91 That's an excellent point.

But OSes aren't nearly secure. It's a tremendous attack surface. Which I suppose also means secure boot is kind of pointless, but without any firmware security anything that compromises the OS is likely to *also* be able to persist in the firmware, which means it'll survive the standard response people have to a malware infection, which is to wipe and reinstall.

I'm not saying "therefore secure boot is good". I'm just wondering what we SHOULD be doing, because we're not on the right track.

@freakazoid Right, and that is a legitimate issue, but - and this is the crucial point - that is first and foremost an *operating system* problem.

There's so much more that operating systems could be doing to be much more resilient against this type of issue, like capability security, but aren't. Instead, the problem got shifted to firmware, even though that's a much worse place to address it in in many ways.

(Also: something that fucks with the boot chain can still be removed. There's nothing that makes that *fundamentally* harder than any other kind of software repair, and with sufficient-yet-imperfect security on the OS level, it would be a rare enough occurrence that it can be trivially handled through all the usual repair venues.)

@joepie91 I wonder to what extent all of this has been pushed down into the firmware because of the amount of power Microsoft has to just punt on implementing this shit themselves? Because, at the end of the day, secure boot is a Microsoft thing. Linux is only involved at all because in the desktop world it exists almost entirely on Microsoft's scraps.

And Intel basically has three customers: Microsoft, Google, and Amazon. They have Xeon processors for Linux and Core processors for Windows.

And then there's the Arm world, but that's pretty heavily fragmented.

@freakazoid I guess my more fundamental point here is that the situation with secure boot is similar to that with a lot of snakeoil.

If you start by assuming secure boot, you can certainly retroactively find reasons and justifications why it might be useful. But if you started with a *problem statement of end-user security*, and asked what the most effective and efficient solution would be, you would never end up at "secure boot" as the answer.

That sort of situation is a very reliable red flag for a bad technology choice, often one that has been argued for for undisclosed other reasons rather than the stated one (and I suspect that the 'DRM' and 'corporate hardware' cases are those reasons, here).

@joepie91 I completely agree with that. And this is an area where "Desktop Linux lives on Microsoft's scraps" could really end up screwing Linux: the content cartel (including Microsoft) have this fantasy of pushing DRM all the way down into the storage layer, so that you can't even get to the encrypted bits.

It does feel like desktops are in a slow march toward turning into consoles/mobile phones. Apple is ahead of Microsoft on this. Personal PCs are an ever-diminishing market relative to the total set of computing devices.

@joepie91 The equation probably changes a bit with portable devices. I'm glad I'm able to lock down my bootloader on my phone with GrapheneOS installed. I don't know how feasible it is to inject software on my laptop with physical access, but I should probably lock it down more. How much that matters when I don't have it set up to delete the disk encryption keys from RAM when suspending and usually leave it suspended, I don't know.