de0u I think it might be harder than that. I think there have been a lot of bugs in secure boot in firmware on PCs. For example, "Secure Boot is completely broken on 200+ models from 5 big device makers" (Dan Goodin, Ars Technica, 2024-07-25). If that is accurate, up until 18 months ago a large number of so-called "secure boot" systems were blatantly wrong. Now presumably some of the blatantly wrong systems have improved to being only mildly wrong. Personally I wouldn't rush to assume that in general PC "secure boot" implementations are actually right!
Here is another example:
For the last half year I have created a modified version of Linux Mint with full boot security. I use Secure Boot with custom signing keys to protect kernel, initrd, boot arguments, and a immutable file system image including apps and app configuration, such that even if the system is compromised at root or kernel level, a simple reboot will guarantee that it is booted back into unmodified pristine uncompromised state. I also use TPM PCR registers to implement a "maintenance mode" in which you can make modifications, such as installing software updates, similar to how QubesOS have templates.
My first choking discovery: I enabled Secure Boot with my custom signing key on an MSI motherboard with fully up-to-date UEFI firmware, but it would still happily boot any EFI image not signed by my key. Worse, the UEFI firmware logged to the TPM event log that Secure Boot is enabled and in enforce mode, and that PK, KEK and db variables are configured such that only EFI images signed with my key can be loaded. Even if it booted an EFI image not signed with my key. Turns out I was not the only one who had discovered this, with others having reported it to MSI as a security issue.. many years ago, with no response or action taken from MSI's side. Turns out MSI didn't want Secure Boot to interfere with usability on their desktop motherboards used for home builds, so they had added another non-standard setting they call image execution policy, with the default value of "Always Execute" on policy violations, to all such motherboards. But this still means attestations from the TPM PCR registers cannot be trusted, ever, since that non-standard value is not logged, and attestation thus do not guarantee any security at all.
I mean, this is almost as bad as shipping test keys as ultimately trusted. But this also affects Secure Boot configurations with custom key hierarchy rather than the default vendor key hierarchy.
Secure Boot itself is fine, and secure. But just like only Pixel phones have good hardware security in the phone world, I think we will need to be picky about hardware vendors for desktop and laptop computers too if we start implementing security features on top of Secure Boot and TPM. MSI hardware with stock UEFI firmware is totally disqualified at least.