Caliptra Core ROM: TOCTOU in update-reset lets compromised MCU firmware bypass secure boot silently

Impact

Caliptra is the open silicon root of trust that datacenter CPUs, GPUs, DPUs and SSDs increasingly rely on to attest their own firmware. In subsystem mode the update-reset flow accepts an AXI staging address without checking it against the strap-configured SS_EXTERNAL_STAGING_AREA_BASE_ADDR, so an attacker who already controls the MCU firmware can point Caliptra at unprotected SRAM and swap the image between verification and load into ICCM. The result is that arbitrary firmware runs while attestation keeps reporting the digest of the image that was originally verified - the measurement chain the operator uses to decide whether a node is trustworthy reports clean. For a fleet that gates workload placement or confidential-computing tenancy on attestation, that is the one failure mode that cannot be detected from above: a node stays in the pool, keeps passing its health and attestation checks, and is no longer running the firmware you think it is. Affected versions are Core ROM 2.1.0 through 2.1.1.

Who can reach it

Local and pre-authenticated in the hardware sense: the attacker must already have compromised MCU firmware holding AXI manager access to SRAM that Caliptra can read. Not reachable from a tenant workload or over the network on its own - it is a chain step that converts MCU compromise into a persistent, attestation-invisible root-of-trust bypass.

What to do

The advisory names Core ROM 2.1.0 through 2.1.1 as affected and points at the caliptra-sw GHSA for the fix. Core ROM is silicon ROM, not a field-updatable blob, so what an operator can actually do depends on the part: ask the hardware vendor which Caliptra ROM revision shipped in the boards you own, and whether their remedy is a new stepping, a subsystem-mode configuration change, or nothing. Until that answer arrives the practical control is upstream of the flaw - keep MCU firmware update paths signed and restricted, since the bug is only reachable from an already-compromised MCU. Do not treat attestation results from an affected part as evidence of firmware integrity.

References

Related entries

• Intel processors (indirect branch prediction): Spectre v2: an attacker trains the indirect branch predictor so that aCVE-2017-5715 · Intel processors (indirect branch prediction)Medium
• Intel processors (bounds check bypass): Spectre v1: speculative execution past a bounds check lets an attacker readCVE-2017-5753 · Intel processors (bounds check bypass)Medium
• Intel processors (rogue data cache load): Meltdown: unprivileged code reads kernel memory - and on affected partsCVE-2017-5754 · Intel processors (rogue data cache load)Medium
• Intel processors: speculative sampling of stale data from microarchitectural buffers (MDS)CVE-2018-12126 · Intel processors (microarchitectural data sampling)Medium
• Intel processors (L1 terminal fault, OS/SMM): The OS-level variant of L1 terminal fault: a local user can speculativelyCVE-2018-3620 · Intel processors (L1 terminal fault, OS/SMM)Medium
• Intel processors (rogue system register read): Spectre v3a: speculative reads of system registers leak systemCVE-2018-3640 · Intel processors (rogue system register read)Medium