Manufacturing And Operating System Instructions

Manufacturing and Operating System Instructions

Understanding the releases

Today there are two releases as defined in Secure Boot Objects.

These are v<major>-<minor>-<revision> and v<major>-<minor>-<revision>-signed.

v<major>-<minor>-<revision>

The intention of v<major>-<minor>-<revision> is that they are used by manufacture's to provide reasonable default templates for secure boot. However it is up to manufacture's which defaults they use.

For more information on the firmware details about how to consume these files see Firmware Build Process

How to select which release to use

There are 4 platform specific architectures to choose from:

• edk2-aarch64-secureboot-binaries
• edk2-arm-secureboot-binaries
• edk2-ia32-secureboot-binaries
• edk2-x64-secureboot-binaries

These files today are hash only and are considered the most compatible. These do not revoke the 2011 Windows PCA.

The files included in the architecture specific release are as follows:

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----          1/1/2025   12:00 PM           7636 Default3PDb.bin
-a----          1/1/2025   12:00 PM           2005 Default3PDb.json
-a----          1/1/2025   12:00 PM           3041 DefaultDb.bin
-a----          1/1/2025   12:00 PM            917 DefaultDb.json
-a----          1/1/2025   12:00 PM           1276 DefaultDbx.bin
-a----          1/1/2025   12:00 PM           5093 DefaultDbx.json
-a----          1/1/2025   12:00 PM           3066 DefaultKek.bin
-a----          1/1/2025   12:00 PM            908 DefaultKek.json
-a----          1/1/2025   12:00 PM           1575 DefaultPk.bin
-a----          1/1/2025   12:00 PM            509 DefaultPk.json
-a----          1/1/2025   12:00 PM           6749 README.md
-a----          1/1/2025   12:00 PM              6 version

The JSON files are simply the receipt of the bin files and can be used to validate the binary. The binary files are the EDK2 structured EFI signature lists.

See the template file in the repo for more information.

There is a imaging binary that is provided for firmware that supports an 'empty signature'. See the readme included in the archived release for more information.

• edk2-Imaging-secureboot-binaries

Operating system usage

Operating systems can choose to apply these if the system has secure boot disabled. Some platform implementations may prevent this or have additional requirements like the PK needs to be self signed. These should be performed by an Advanced User.

v<major>-<minor>-<revision>-signed

⚠️ IMPORTANT

This information is for Advanced Users. If you are unfamiliar with the Secure Boot Process it is highly recommended that you allow your Operating System to service Secure Boot. These files are meant for Operating System maintenance needs of operating systems other than Windows (e.g. Linux).

These files assume that the platform trusts a Microsoft Certificate in the KEK (Key Exchange Key).

Listed are some common mistakes but may not document all possible outcomes.

In all assumptions Secure Boot is enabled

Assumption	Effect
Boot media is not updated	System presents "EFI_SECURITY_VIOLATION" dialog to user
Boot media is updated, but enforcement mechanism (e.g. bitlocker) is not suspended	System goes into "Bitlocker recovery"
Boot media is updated, but Cred Guard is not suspended	System loses access to stored creds

See https://learn.microsoft.com/windows/security/identity-protection/credential-guard/

There are currently two variants of the signed files but these may change over time:

1. Traditional Hash based revocation
   1. Most compatible and safe but does not protect against all known issues
2. 'Optional' Certificate and SVN based revocation and DB Update
   1. Provides the best protection but requires new 2023 Boot media.
   2. Some OEM UEFI implementations have trouble with DB Update
      1. For this reason it is not recommended at this time to perform this manually.