1. The spec allows changing keys by the user as far as I know
2. I’m unaware of a proposal of a better concept that stops attacks at this layer

For #2, Full Disk Encryption (including bootloader)

My disk and bootloader are both encrypted but I can get to my UEFI menu without decrypting. I’ve been meaning to password protect that but I get nervous about changing anything in UEFI.

I didn’t know much about secure boot or TPM or PAM so I was planning on setting those up, but I’ll skip it if it’s just about corporate capture. Not that my hardware is from some big name corpo or anything, it came with linux by default. But still.

Also I’m worried about locking myself out of booting from live USBs, especially if I ever need to use a recovery drive. But I think if I understand correctly then most official ISOs should still work, but I’m not 100% certain.

Clearly, I still have a lot to learn…

These protections work at different layers and hence, you use both.

First off, you can’t really encrypt the first boot loader by design, your UEFI needs something it can read and run. You need to protect this first boot stage somehow, and this is what Secure Boot is for; it verifies the signature of the payload it starts to protect it against tampering.

well Android Verified Boot also allows changing keys! but like 15 niche phones implement that function out of thousands. out of which it is broken on several such thatit bricks the phone permanently. further, android hardware attestation can make use of AVB, but virtually no apps use it, every app doing such a verification depends on google play integrity, for which you can’t change keys and still pass the ckecks.

google has already implemented on android what microsoft is only just dreaming of to pull off, despite preparing it since much earlier. I don’t know what they are waiting for, everyone knows there would be no negative consequences to them.