There's a more detailed background on this here: https://mjg59.dreamwidth.org/55845.html
I still think there's plenty of point. I usually don't care about what ring0 can do; I care about what the system can do. Root can steal or destroy my data, or make my system do bad things.
The reason for restricting what kernel will be loaded, is to restrict what will happen at userspace.
A common use-case is bitlocker-style encryption. The system decrypts my harddrive using keys from the TPM. My own userspace is secured at the userspace-level using a login prompt. To defend against an attacker sideloading a different OS, I rely on secure boot to only load my kernel and hence my userspace.
I'm actually having a bit of a hard time finding really good usecases for this lockdown feature. On embedded systems the secure boot keys are often fused in, but I suppose the kernel, but potentially not root, could be able to change the tpm keys on an x86 system?
You could additionally seal the TPM key to specific PCR values so that only booting your kernel would allow using that TPM key.
> kernel, but potentially not root, could be able to change the tpm keys on an x86 system?
Depends on what do you mean by "change". They can't extract private bits but they can remove and add new ones. But if the data is encrypted using the old key it would become bit recoverable.
A non-root can change the entire TPM chip on an x86 system...