The thing is in such a case secureboot doesn’t help and is unnecessary. Secureboot only does anything for the concept of “trusted suppliers”.

If the system has available signing keys for itself, well, hypothetical malware could sign itself using those same keys The OS security mechanisms are the only things protecting that, and in which case the signature validation is redundant.

You can have trusted boot, e.g. LUKS volume sealed to TPM PCRs, but secureboot just doesnt make sense as a mechanism for a user to only trust themselves.

I have seen some platforms locked to Microsoft first party keys only. They boiled the frog by starting with it being optional, able to enroll your own keys, and Microsoft signing third party bootloaders, but now there exists a Microsoft-only certificate regime that at least some vendors have selected, or at least made a selectable option. The pitch being that Windows shops that don’t trust their users can be assured they aren’t deviating from the blessed windows os their IT trusts.

Nvidia can’t meaningfully sign their Linux drivers. A distribution can, in theory, include Nvidia drivers in their build and sign it, but the logistics of out of tree drivers is just impossible.

Redhat toys with the concept of a whitelisted ABI for some limited range of kernels, but I’ve never seen a driver actually roll with that.

Basically Linux would need to embrace some form of ABI, and there’s been zero interest in doing so.

Instead of new SSNs, how about we maybe the number less risky in general?

It should never have served as a “secret”. Authenticating someone needs more than some account number. SSN should be more of a “username”, not a password.