Provide a way to prevent unconditional trust to built-in (vendor) certificate

The issue names no files or tests. Start by tracing shim's handling of built-in certificates, MokList, NVRAM variables, and SBAT, then determine where the proposed trust restriction belongs. Done means defining and implementing the variable behavior, including the alternative-certificate safeguard and required SBAT change.

Hi devs,

With ongoing adoption of UKIs it's now possible to build trust chain from UEFI firmware up to early userspace code driven by initrd/initramfs embedded into signed UKI. The approach is used to perform automatic TPM2-based LUKS device unlocking during initrd phase. TPM2 policies may be configured in a way to prevent automatic unlocking when unexpected boot code is involved but there is no way to prevent unexpected early userspace from being invoked (which may be used i.e. to spoof LUKS device password prompt).

Even if UKI is signed with a custom user key/cert there is still a possibility to run arbitrary unsigned initrd/initramfs code in conjunction with kernel signed by built-in (vendor) key/cert. The workflow is perfectly supported by shim-based setups due to legacy reasons.

The problem is that built-in cert cannot be un-enrolled to prevent unsigned initrd/initramfs workflow. Even if mokutil --delete is used against built-in cert, it's still populated into MokList and unconditionally trusted on next boot. Hence the proposal is to introduce NVRAM variable to prevent unconditional trust to the built-in certificate. Shim's SBAT Level have to be bumped in addition.

The approach may be considered too strict and soft-brick systems that do not have alternative certificates in MokList. Hence logic based on proposed NVRAM variable may check if there is alternative certificate enrolled into MokList.

P.S.: Other considered approaches:

1. Add built-in certificate to MokListX. It works to some extent. However given there are plenty of shim versions that carry certs for other vendors and distros, it's not easily manageable to track and block them all. Otherwise it's still possible to drop a shim + kernel from unblocked distro onto ESP.

2. Deploy custom PK and KEK. Looks like an overkill and not perfectly compatible approach due to multi-boot setups and Option ROMs.