> In 2012 Microsoft started requiring vendors ship systems with UEFI Secure Boot, a firmware feature that allowed[5] systems to refuse to boot anything without an appropriate signature. This not only enabled the creation of a system that drew a strong boundary between root and kernel, it arguably required one - what's the point of restricting what the firmware will stick in ring 0 if root can just throw more code in there afterwards?

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?