Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage UEFI bootloader that is used by Linux distributions to boot the kernel with Secure Boot. But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the hardware vendor to issue an update for the system firmware, which may or may not happen. It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.
Secure Boot is a really contrived and, frankly, bad defense against an attack that is extremely difficult to execute in reality and does not happen often (are there any examples of a bootloader replacement against a home desktop in the wild?).
An actually good solution would be firmware support for LUKS-style FDE (with a password-encrypted key which then encrypts the rest of the disk), so that your bootloader is encrypted with the rest of your system and impossible to substitute without erasing the rest of the disk, until you enter the password. This way there’s no need for key enrolment into firmware, and firmware manufacturers don’t have to just trust MS. (the firmware of course needs to be protected too, by signing it with the manufacturer’s key; if you flash something unsigned, a warning pops up Android-style before every boot).
If you are hiding something from the state (like your sexual orientation or something), your energy is much better spent encrypting your communications online and keeping your identities anonymous. If you are already suspicious enough to try and pull a bootloader replacement attack on you, any authoritarian state which would do that in the first place will just throw you in jail and fabricate evidence as needed.
The main advantage of SB is TPM. At runtime the key isn’t available and unlocking your disk works automatically as long as nothing has been tampered with (which is then also a nice canary: if you suddenly have to enter your password during boot, something’s off).
There’s nothing technically preventing using TPM without secure boot. This is a limitation imposed by OEMs. In fact I have a separate hardware encryption key that I encrypt my (laptop) drive with, and even I don’t (can’t) know the private key. I only know the pin that is needed to unlock it. If motherboard OEMs implemented something like this on the motherboard, with the ability to decrypt the bootloader partition before booting into it, this would solve everything.