Do x64 machines differ in their secure boot implementations and ROM certificates?
I'm trying to understand secure boot and the key requirements in ROM firmware for x86 machines
I'm coming from this definition of secure boot:
The PCs are sold with certain certificates embedded in the ROM firmware. That ROM firmware will only run an UEFI application if it verify signature with one of those certificates.
Having that as a definition my question is:
- Do secure boot implementations vary between x86/x64 PCs?
- An OS image working on one PC fails to securely boot on another
- Is there a predefined set of certificates available on all firmware ROMs?
Solution 1:
Do secure boot implementations vary between x86/x64 PCs?
They do, just like the rest of the firmware varies. Some manufacturers' firmwares might share common heritage (using the Tianocore open-source implementation as their basis) but unlikely that they work exactly the same after each manufacturer has adapted it to their own systems.
Basic things like signature validation should, in theory, work the same everywhere (disregarding bugs and ambiguities in the specification). However, the user interface differs greatly (some implementations have extensive UIs for manual customization of the certificate lists, others have handy pre-set "Windows" and "non-Windows" templates for controlling SB & CSM, yet others have only the bare minimum.) Limits also differ, sometimes influenced by hardware, e.g. the total number of certificates in db or revoked hashes in dbx might not be the same.
The requirements also do vary. For example, on ARM devices, Microsoft really wants nothing else but Windows to be allowed – no third-party operating systems. Whereas on x86 devices the default is to allow them and the firmware is even required to allow the user to fully customize the certificate lists via physical access.
Is there a predefined set of certificates available on all firmware ROMs?
In practice, Secure Boot "out of the box" requirements are set by Microsoft. Here's their guide.
Generally, there is only one stable Secure Boot CA (which manufacturers are required to include if they want to pass whatever product certification thing Microsoft has), which is labelled "Microsoft Windows Production PCA 2011" and is used exclusively for signing the Microsoft Windows boot files.
The other Microsoft-provided CA is "Microsoft Corporation UEFI CA 2011", which is the one used by Microsoft to sign various third-party software, such as some Linux distributions' boot files (including Shim and Preloader), as well as Option ROMs embedded in hardware. This CA, while very widely available, is nevertheless just something "the OEM should consider including".
If I understand correctly, it is often included to make external GPUs or NICs work in the UEFI environment (that is, before the OS starts up). However, some computers specifically have a firmware settings option to disable this CA, either to avoid security risks (e.g. buggy Linux GRUB versions) or to make the system compliant with Windows 10 Device Guard.
That's where the "predefined" list ends.
Some computers may also include e.g. the manufacturer's own CA (such as HP's, presumably to allow their recovery/admin tools to work), or Canonical Ltd.'s CA (which is used for Ubuntu Linux), but none of those are anywhere near universal.