[DyslexicAtheist]

I was with you until secureboot.

At least on my Debian I retain full control using the shim and my own enrolled keys. So seems less an issue with the technology but perhaps with how some vendors (that are already locking you in anyway) use secureboot?

from https://wiki.debian.org/SecureBoot

>> Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for as a trust root for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

[candiddevmike]

In theory the benefits of secureboot around attestation and hashing/measuring of boot components do not require a secure/verifiable chain of custody. You could self verify using PCRs. The boot loader signing aspects were always for control and restricting devices, IMO.

[blueflow]

> The boot loader signing aspects were always for control and restricting devices

Not surprising, given the huge role Microsoft had in developing this.

You can't enroll your MOK without booting up, and you can't boot up if Microsoft hasn't signed your bootloader/kernel... It used to be an no-brainer and now its difficult.

[dathinab]

this is simply not true

only using self verifying of PCRs is not an effective protecting against most attacks. (Against which a secure boot chain is supposed to help.)

Sure it depends a bit on what you want from secure boot. But in general if you need PCRs you also need to make sure only verified code can run. If you don't, you likely don't need PCRs either, and some simple flawed secure module key storage would work as good.

In a certain way having a trust verification of the boot loader is the most important part. Everything after that depends on how the boot loader is implemented, through having PCRs is still helpful.

Through this is where secure boot failed (very hard), as long as you don't enroll your own keys you are not really getting a secure boot chain. Something which IMHO is fundamental requirement for any company laptops and similar. (Or, instead of using custom PKs, you are MS and disable all 3rd party keys and disable any BIOS option to add/enroll 3rd party keys, like they did on some older ARM devices).

I.e. IMHO a secure boot chain and protocols related to it are a must have, but the current implementation is garbage, especially for most Windows users.

If you want to know in which direction things could be done you could look a ARM Mac Books more specifically the documentation Asahi Linux created for it. Through just the direction not the exact design.

Basically for PCs (even in huge companies with MDA) you don't need global trust chains, just local per-system trust automatically setup on first boot after "reset" and making sure a "reset" is roughly like a wipe (by using full disk encryption) is all you need (and want). The devil is in the details, but it isn't really that hard to make it work.

[raxxorraxor]

Personally I don't get any benefits from secure boot and it is already used to verify the alleged integrity of systems. Not sure how using your own keys would work for remote attestation, it probably wouldn't. Healthy experience with the industry and the market tells me the future if such systems are widely adapted. And that would be a net negative for software freedom that is beyond the security gains, which can be reached through other means as well.