That's precisely why secure boot and TPMs exist - the TPM can store the keys to decrypt the drives and won't give them unless the signed shim executable can be verified; the shim executable then checks the kernel images, options, and DKMS drivers' signatures as well. If the boot partition has been tampered with, the drive won't decrypt except by manual override.

The big problem is Microsoft controls the main secure boot certificate authority, rather than a standards body. This means that either a bad actor stealing the key or Microsoft itself could use a signed malicious binary used to exploit systems.

Still, it's at least useful against petty theft.

TPM sniffing attacks seem possible, but it looks like the kernel uses parameter and session encryption by default to mitigate that: https://docs.kernel.org/security/tpm/tpm-security.html

There’s also PXE boot, secure boot, carrying around a live image on a flash drive, etc.

But any attacker advanced enough to tamper with your EFI partition in an evil-maid scenario has plenty of other options to log and steal your encryption passphrase, so it’s generally a moot point.

This is more nitpicking. Yes, there's a difference between partition and disk. But if we want to get technical, it's not disk encryption unless you're using a HDD. SSDs don't have disks.

At the end of the day, FDE would generally imply that all partitions with user data on them are encrypted. So it would generally include root and home partitions, and generally not include the boot partition, and would likely include partitions like /var and /opt, though not necessarily.

As bad as secure boot is, that's exactly the use case for it. Frankly, you can both swap the CD and solder a new BIOS flash if you are really interested in boot poisoning, the latter is just a tiny bit harder to do without some sort of trace.

Mainly because then the manufacturer decides on how your stuff is encrypted, no likie.

You are just moving things. When you change your EFI partition from being unencrypted and asking for your password to the BIOS asking for your password (or other credentials) you just shift the attack surface.

Somewhere there has to be an unencrypted part to start with.

Lock your unencrypted ESP down with secure boot and your own keys (shitty as it is that is in fact the one conceptional usecase of secure boot, not that stupid marketing bullshit MS is doing with getting vendors to pre-install Microsoft keys) to prevent tampering and you are good to go.