The isolation provided by the kennel is strictly more vulnerable than a TPM chip that can only interacted with via a communication protocol. Using the TPM, the hardware bootloader can verify that it boots only authorized, untainted kernel images. Without it, a chain of exploits can be used to taint the kernel boot image, thus effectively take over the machine. Even if an exploit chain succeeds in gaining root access, it's gone the next time the machine reboots.

The crucial problem is that the IT industry is more concerned about using it to enforce DRM instead of educating users so they can use it to retain ownership of their services.

So what's preventing chain of exploits from just using the TPM over communication protocol to do whatever it needs that requires said TPM to sign/attest to something?

For the same reason a website can't ask the browser to simply install another root certificate into its truststore: a browser simply doesn't offer an interface to do that.

The TPM itself does very little. It is simply used by the UEFI to verify that the digital signature of the OS image is valid, similarly to how a browser validates a server certificate using its own truststore.

A possible attack vector to compromise that functionality would be to tamper with UEFI. Since it is firmware, the operating system simply doesn't have the capability to so. Even when doing firmware updates, the OS must ask the UEFI nicely to apply a new firmware image, which is similarly verified using a digital signature.

All the above assume that there are no backdoors that allow an upper layer to compromise a lower layer.

That doesn't make much sense. You don't need any private material to verify signatures when using asymmetric cryptography. How's TPM useful at all if all it does is verify signatures?

The TPM had multiple functions, and for verifying operating system images indeed no private key is required. For that to work, it is merely required that the OS doesn't have write access to the TPM.

Private key material is required for remote attestation, which makes it possible to prove certain things to an external party, for example the exact identity of the TPM. This feature is much more questionable.

> The isolation provided by the kennel is strictly more vulnerable than a TPM chip that can only interacted with via a communication protocol.

That's a useful property, but you have to weigh it against a kernel that can be audited and patched.

Whether the kernel can vbe audited is completely orthogonal to verifying it at boot time since there are still ways to retrieve it even with active hardware encryption.

The utility of patching your own kernel has to be carefully weighted against the security impact of doing so. If an attacker can take over the user account that compiles the kernel, they can make you install a compromised kernel. For example, by running a file system monitor that exchanges the kernel image with a compromised one as soon as it has been built.

If you can assume that the TPM has no vulnerability, I can assume that the kernel has no exploit. QED