A more detailed writeup of how the FSF is not only wrong about TPMs being involved in hardware-based DRM, they missed the actual user-hostile hardware DRM implementation: https://mjg59.dreamwidth.org/70954.html
@tthbaltazar@mjg59 It's not trivial to sniff if you use a fTPM or similar, since then it's buried deep inside the CPU itself. But yes, physical access can still be a risk, since the attacker could for instance sniff the memory bus; but that's a more complex attack than "plug a USB stick and boot from it" or even "sniff the low speed LPC bus".
(Some computers have "intrusion switches" to sense when the case is opened, but I don't think they set any flag the TPM can use as a sign to stop.)
@cesarb@tthbaltazar@mjg59 Don’t confuse on-package TPMs and fTPMs. A lot of fTPMs (which run on the main core in a privileged mode) are often vulnerable to side channels. Several of the recent transient execution attacks could leak fTPM secrets. I think most of these were patched by doing some aggressive state flushing on TPM events, but people keep finding new side channels. On-package TPMs, where the TPM is a separate component either in the same package or on the same die are typically not vulnerable to these attacks. On the MS Surface laptops, there’s a Pluton subsystem on die, which runs the TPM stack. Pluton is one of the few Microsoft security products I have a lot of faith in (I worked with that team, they’re great): it stood up to over a decade of attacks from people with physical access and a strong financial incentive to break it.
@tthbaltazar@mjg59 One common use of a TPM is to have a full-disk-encrypted partition which is automatically decrypted as long as the full both path (firmware, bootloader, kernel, initrd, kernel command line, etc) is unchanged. Try to access it any other way (single user mode, booting from a USB stick, etc) and it won't automatically decrypt (you'd have to use alternate means, like a recovery passphrase).