Summary
runtime/src/drivers.rs → initialize_dpe() hardcodes svn: 0 when replaying ROM measurement log entries into DPE, even though MeasurementLogEntry stores the SVN provided by the caller. This means measurements stashed during ROM phase lose their SVN in DPE — affecting CDI derivation, X.509 certificates, and anti-rollback guarantees.
Branch
main branch of caliptra-sw (commit 083d7946), which uses caliptra-dpe at commit cfc9a71 (on caliptra-dpe main).
Note: The main-2.x branch pins an older DPE (f56f66e, runtime-1.2 branch) that does not have SVN in DeriveContextCmd, so this bug only manifests on the main branch which uses the newer DPE with SVN support.
Affected Code
The Bug — runtime/src/drivers.rs lines 713-726
ROM measurement log replay in initialize_dpe() hardcodes svn: 0:
```rust
let result = DeriveContextCmd {
// ...
tci_type,
target_locality: pl0_pauser_locality,
svn: 0, // <--- BUG: should be measurement_log_entry.svn
}
```
ROM correctly stores SVN
rom/dev/src/flow/cold_reset/fw_processor.rs saves stash_measurement.svn into MeasurementLogEntry.svn.
RT stash correctly passes SVN
runtime/src/stash_measurement.rs line 66 passes svn from the caller to DeriveContextCmd.
Impact
- CDI derivation is wrong — The derived CDI does not reflect the actual SVN of ROM-phase measured components.
- Certificates misreport SVN — X.509 MultiTcbInfo shows SVN=0 for ROM-phase measurements regardless of actual value.
- Anti-rollback is weakened — SVN-based anti-rollback cannot detect firmware rollback for ROM-phase measured components.
- Inconsistency — The same STASH_MEASUREMENT gets different DPE treatment depending on whether it was sent before or after RT firmware is running.
Reproduction
Send STASH_MEASUREMENT with svn=42 via both ROM and RT paths, then compare the DPE leaf certs:
ROM-stash path TcbInfo entries:
tci_type: TEST, svn: 0 <-- BUG: should be 42
RT-stash path TcbInfo entries:
tci_type: TEST, svn: 42 <-- correct
Proposed Fix
One-line change in initialize_dpe():
```rust
svn: measurement_log_entry.svn, // was: svn: 0,
```
Summary
runtime/src/drivers.rs→initialize_dpe()hardcodessvn: 0when replaying ROM measurement log entries into DPE, even thoughMeasurementLogEntrystores the SVN provided by the caller. This means measurements stashed during ROM phase lose their SVN in DPE — affecting CDI derivation, X.509 certificates, and anti-rollback guarantees.Branch
mainbranch of caliptra-sw (commit083d7946), which uses caliptra-dpe at commitcfc9a71(on caliptra-dpemain).Note: The
main-2.xbranch pins an older DPE (f56f66e,runtime-1.2branch) that does not have SVN inDeriveContextCmd, so this bug only manifests on themainbranch which uses the newer DPE with SVN support.Affected Code
The Bug —
runtime/src/drivers.rslines 713-726ROM measurement log replay in
initialize_dpe()hardcodessvn: 0:```rust
let result = DeriveContextCmd {
// ...
tci_type,
target_locality: pl0_pauser_locality,
svn: 0, // <--- BUG: should be measurement_log_entry.svn
}
```
ROM correctly stores SVN
rom/dev/src/flow/cold_reset/fw_processor.rssavesstash_measurement.svnintoMeasurementLogEntry.svn.RT stash correctly passes SVN
runtime/src/stash_measurement.rsline 66 passessvnfrom the caller toDeriveContextCmd.Impact
Reproduction
Send
STASH_MEASUREMENTwithsvn=42via both ROM and RT paths, then compare the DPE leaf certs:Proposed Fix
One-line change in
initialize_dpe():```rust
svn: measurement_log_entry.svn, // was: svn: 0,
```