| @@ -1,26 +1,8 @@ |
| 1 | 1 | <div style="font-size: 0.85em; color: #656d76; margin-bottom: 1em; padding: 0.5em; background: #f6f8fa; border-radius: 4px;"> |
| 2 | | -📄 Source: <a href="https://github.com/chipsalliance/caliptra-sw/blob/cddb376171e1e39f16484b44965a68e93fcb461a/fmc/README.md" target="_blank">chipsalliance/caliptra-sw/fmc/README.md</a> @ <code>cddb376</code> |
| 2 | +📄 Source: <a href="https://github.com/chipsalliance/caliptra-sw/blob/51ff0a89f169bbf8e06acb49b31db555e99fefb6/fmc/README.md" target="_blank">chipsalliance/caliptra-sw/fmc/README.md</a> @ <code>51ff0a8</code> |
| 3 | 3 | </div> |
| 4 | 4 | |
| 5 | 5 | # Caliptra - FMC Specification v1.0 |
| 6 | | - |
| 7 | | -## Version History |
| 8 | | - |
| 9 | | -| Date | Version | Description | |
| 10 | | -| :--------- | :------ | :---------------------------------------------------------------------------------- | |
| 11 | | -| 01/18/2023 | 0.1 | Document Created, Boot flow defined | |
| 12 | | -| 01/31/2023 | 0.1.1 | Added Overview and Pre-Conditions sections | |
| 13 | | -| 02/10/2023 | 0.2 | Incorporate feedback and decisions from Caliptra WG meetings | |
| 14 | | -| 02/27/2023 | 0.4 | Update for decision that Anti-Rollback will be entirely handled by ROM | |
| 15 | | -||| Add details/clarifications in FMC Boot steps including where to store artifacts | |
| 16 | | -||| Add Firmware Handoff Table (FHT) definition | |
| 17 | | -| 03/21/2023 | 0.5 | Additional fields added to FHT | |
| 18 | | -| 03/29/2023 | 0.5.1 | Changed the value for invalid address fields in FHT | |
| 19 | | -| 06/27/2023 | 0.7 | Add state of data and key vaults before/after FMC execution | |
| 20 | | -| 06/30/2023 | 0.7.1 | Simplify reset/update/recovery sections | |
| 21 | | -||| Add more PCR handling details | |
| 22 | | -| 03/04/2024 | 1.0 | Finalize as version 1.0 specification | |
| 23 | | - |
| 24 | 6 | |
| 25 | 7 | ## Scope |
| 26 | 8 | |
| @@ -55,7 +37,7 @@ |
| 55 | 37 | First Mutable Code (FMC) is the first field-updatable firmware module in the Caliptra boot sequence. It is loaded, cryptographically verified, |
| 56 | 38 | and executed by the Caliptra ROM. |
| 57 | 39 | |
| 58 | | -### Pre-Conditions / Assumptions |
| 40 | +### Pre-conditions / assumptions |
| 59 | 41 | |
| 60 | 42 | It is assumed that the Caliptra ROM has already performed a series of steps to prepare the Caliptra environment before calling the FMC entry point. The |
| 61 | 43 | following is a brief overview of those expectations. Further details can be found in the Caliptra ROM Specification. |
| @@ -88,7 +70,7 @@ |
| 88 | 70 | |
| 89 | 71 | </center> |
| 90 | 72 | |
| 91 | | -### FMC Responsibilities |
| 73 | +### FMC responsibilities |
| 92 | 74 | |
| 93 | 75 | FMC can be thought of as essentially a small, mutable extension of the ROM. Its primary purpose is to bridge execution from the immutable ROM code, prepare the |
| 94 | 76 | environment for the main runtime firmware, and then execute that runtime firmware. As such, the code should be kept to the bare minimum needed to perform that |
| @@ -107,7 +89,7 @@ |
| 107 | 89 | CDI<sub>FMC</sub> and PrivateKey<sub>FMC</sub> unavailable. |
| 108 | 90 | - FMC must execute the Runtime Firmware Module. |
| 109 | 91 | |
| 110 | | -## Firmware Handoff Table |
| 92 | +## Firmware handoff table |
| 111 | 93 | |
| 112 | 94 | The Firmware Handoff Table is a data structure that is resident at a well-known location in DCCM. It is initially populated by ROM and modified by FMC as a way |
| 113 | 95 | to pass parameters and configuration information from one firmware layer to the next. |
| @@ -306,14 +288,14 @@ |
| 306 | 288 | |
| 307 | 289 | This area is reserved for definition of additional fields that may be added during Minor version updates of the FHT. |
| 308 | 290 | |
| 309 | | -## PCR Registers |
| 291 | +## PCR registers |
| 310 | 292 | |
| 311 | 293 | FMC has the responsibility to update 2 PCR registers.<br> |
| 312 | 294 | FMC updates PCR3 to reflect the firmware update Journey with measurements of RT firmware and FW Manifest. This register is only cleared on cold reset.<br> |
| 313 | 295 | FMC updates PCR2 to reflect only the Current running firmware with measurements of RT firmware and FW Manifest. This register is cleared on all reset types.<br> |
| 314 | 296 | FMC locks its PCR registers before handing control to RT firmware so that they may not be cleared later in the boot. |
| 315 | 297 | |
| 316 | | -## FMC Boot Flow |
| 298 | +## FMC boot flow |
| 317 | 299 | |
| 318 | 300 | The following list of steps are to be performed by FMC on each boot when ROM jumps to its entry point. Any failures are considered fatal. |
| 319 | 301 | |
| @@ -341,8 +323,9 @@ |
| 341 | 323 | 1. FMC locates the Runtime FW Module in ICCM at fht.rt_fw_load_addr. |
| 342 | 324 | 1. FMC jumps to the Runtime FW Module entry point at fht.rt_fw_entry_point. |
| 343 | 325 | |
| 344 | | -**Pre-Conditions:** |
| 345 | | -* Vault state as follows: |
| 326 | +**Pre-conditions:** |
| 327 | + |
| 328 | +- Vault state as follows: |
| 346 | 329 | |
| 347 | 330 | | Slot | Key Vault | PCR Bank | Data Vault 48 Byte (Sticky) | Data Vault 4 Byte (Sticky) | |
| 348 | 331 | | ------ | ----------- | ---------- | ----------------------------- | ---------------------------- | |
| @@ -419,10 +402,12 @@ |
| 419 | 402 | RT->>RT: RtFwInitFlow() |
| 420 | 403 | deactivate RT |
| 421 | 404 | ``` |
| 405 | + |
| 422 | 406 | </center> |
| 423 | 407 | |
| 424 | | -**Post-Conditions:** |
| 425 | | -* Vault state as follows: |
| 408 | +**Post-conditions:** |
| 409 | + |
| 410 | +- Vault state as follows: |
| 426 | 411 | |
| 427 | 412 | | Slot | Key Vault | PCR Bank | Data Vault 48 Byte (Sticky) | Data Vault 4 Byte (Sticky) | |
| 428 | 413 | | ------ | ----------- | ---------- | ----------------------------- | ---------------------------- | |
| @@ -443,7 +428,7 @@ |
| 443 | 428 | FMC does not distinguish between cold boots or any other type of reset. Instead, FMC is designed such that it always performs the same set of operations |
| 444 | 429 | regardless of which reset path caused it to be executed. |
| 445 | 430 | |
| 446 | | -## Update and Recovery |
| 431 | +## Update and recovery |
| 447 | 432 | |
| 448 | 433 | FMC does not participate in Caliptra update/recovery flows. FMC is designed such that it does not perform any different steps during update |
| 449 | 434 | and simply behaves the same as it does during other cold/warm resets. |
| @@ -456,6 +441,7 @@ |
| 456 | 441 | Currently, Fake FMC directly proceeds to runtime without generating the RT Alias Cert. In the future, there will be a static cert and a corresponding private key will be used by runtime to support the DICE challenge flow. |
| 457 | 442 | |
| 458 | 443 | **How to use:** |
| 444 | + |
| 459 | 445 | - Fake FMC is provided in the release along with the normal collateral. |
| 460 | 446 | - The image builder exposes the argument "fake" that can be used to generate the fake versions |
| 461 | 447 | |