Skip to content

Commit 1881b6e

Browse files
Merge pull request #1248 from Dasharo/add_redundancy_docs
docs/guides/redundancy.md: add ibg and cbfs verification
2 parents 642d7bc + 41a2f44 commit 1881b6e

1 file changed

Lines changed: 43 additions & 3 deletions

File tree

docs/guides/redundancy.md

Lines changed: 43 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -47,10 +47,50 @@ This command sequence writes the new firmware image into the appropriate regions
4747
`attempt_slot_b` CMOS option to "Enable". This ensures that after the next
4848
reboot, the system will boot from the newly updated slot.
4949

50+
## Security: Chain of Trust with TrustRoot and CBFS Verification
51+
52+
### Slot Integrity via CBFS Verification
53+
54+
Each redundancy slot is protected by **CBFS Verification**: the bootblock
55+
contains cryptographic hashes of all other CBFS files, and each file's hash
56+
is checked before it is loaded. This ensures that any corruption or tampering
57+
within a slot is detected before the affected code runs, regardless of which
58+
slot is active.
59+
60+
### Dasharo TrustRoot Integration
61+
62+
When TrustRoot is enabled, it extends the root of trust into hardware.
63+
On every boot, the Boot Guard ACM — executed directly by the CPU before any
64+
firmware code runs — cryptographically verifies the **bootblock** of the active
65+
slot. Because the bootblock in turn holds the CBFS hashes, a single hardware
66+
verification anchors the integrity of the entire slot.
67+
68+
The full chain of trust proceeds as follows:
69+
70+
1. **Boot Guard ACM** (hardware) verifies the active slot's bootblock.
71+
2. **Bootblock** uses CBFS Verification to check and load `romstage`.
72+
3. Each subsequent stage verifies the next until the **UEFI payload** is
73+
reached.
74+
4. **UEFI Secure Boot** takes over to verify OS boot loaders and drivers.
75+
76+
### Interaction with Top Swap
77+
78+
The Top Swap mechanism selects which bootblock the CPU presents to Boot Guard
79+
at reset. Boot Guard verifies whichever bootblock is currently mapped (slot A
80+
or slot B), so both slots must be signed with the same key for the platform to
81+
boot successfully from either. A CMOS reset falls back to slot A, which is the
82+
read-only golden copy — ensuring there is always a known-good, Boot Guard
83+
verified image available for recovery.
84+
85+
!!! note
86+
87+
The CMOS-backed `attempt_slot_b` bit selects the active slot; physically
88+
removing or shorting the CMOS battery resets this bit and unconditionally
89+
restores slot A as the boot target.
90+
5091
## Further reading
5192

5293
For a more detailed documentation of the implementation, please read the
53-
[upstream coreboot documentation](https://doc.coreboot.org/soc/intel)
54-
(_"doc.coreboot.org/soc/intel/redundancy.html"_, not yet available as of
55-
February 25th 2026, can also be viewed
94+
[upstream coreboot documentation](https://doc.coreboot.org/soc/intel/redundancy.html)
95+
(can also be viewed
5696
[here](https://github.com/coreboot/coreboot/blob/main/Documentation/soc/intel/redundancy.md)).

0 commit comments

Comments
 (0)