Patterns in the Secure Boot Chain
- 1.Firmware[N] - the N level firmware binary. Any firmware layer is updatable.Firmware means the component verified by Hardware.Firmware[N] means the component verified by Firmware[N-1].It may include both code (Firmware[N].Code) and data (Firmware[N].Data).
- 2.Firmware[N].Code - the code of the N level firmware binary.It may include the verifier (Firmware[N].Code.Verifier.)
- 3.Firmware[N].Data - the data of the N level firmware binary.It may include the verification policy. (Firmware[N].Data.Policy.)
- 4.Firmware[N].Code.Verifier - the verification function of the N level firmware binary.
- 5.Firmware[N].Data.Policy - the policy data inside of the N level firmware binary. This data is used by the verification function. Both verification function and policy data have below subcategory:
- 1.Boot - the firmware boot
- 2.FirmwareUpdate - the firmware update (it may or might not include policy data)
- 3.PolicyUpdate - the policy update. It may or might not exist.
- 4.Recovery - the firmware recovery
- 5.Communication - the firmware runtime communication
- 6.Hardware – the hardware, including Register Transfer Level (RTL) and register. The hardware is not updatable. The hardware must be fused when it is shipped to the end user.
There are two types of verification:
- 1.The verifier for boot (verified boot). The read-only code and read-only data are in this category. This category includes both initial installation and upgrade. For example, UEFI Secure Boot is for code installation, or signed capsule update is for code/data upgrade. In most cases, the verification is based upon a crypto-algorithm, such as Secure Hash Algorithm (SHA) or Rivest-Shamir-Adleman Algorithm (RSA). The policy data can be the hash value of the firmware or the public key hash of the firmware. Above 5.a, 5.b, 5.c, 5.d belongs to this type.
- 2.The verifier for communication (verified communication). The read/write data are in this category. This category is for cross-boundary data passing such as SMM communication, including the UEFI non-volatile variable. In most cases, the verification is based upon the boundary check, valid range check, etc. Above 5.e belongs to this type.
Table 1-3: Patterns for Verified Boot
NOTE: If N == 0, Firmware[-1] means the hardware.
Table 1-4: Patterns for Verified Policy Update
Table 1-5: Patterns for Verified Firmware Update
Table 1-6: Patterns for Verified Recovery
Table 1-7: Patterns for Verified Runtime Communication