Closed korran closed 1 year ago
The reason disable_attestation tries to use KEY_ID_RT_CDI in generate_dice_key is because we previously thought that erasing a key vault slot and then reusing it later would cause that key vault slot to be read as all 0s.
I wrote the test test_derive_ecc_key_from_cdi_in_erased_kv_slot to check this, but looks like this test passed in the integration tests, but not the verilator/FPGA.
This test is failing on both FPGA and verilator models:
As best as I can tell, the runtime firmware is trying to disable attestation at https://github.com/chipsalliance/caliptra-sw/blob/da0cf516fdcea1b6f388567927f33e9f0c9f65da/runtime/src/drivers.rs#L216-L218, but that is failing with error code DRIVER_HMAC384_READ_KEY_KV_READ for key id KEY_ID_RT_CDI. I'm guessing this is a bug because KEY_ID_RT_CDI was just erased at https://github.com/chipsalliance/caliptra-sw/blob/da0cf516fdcea1b6f388567927f33e9f0c9f65da/runtime/src/disable.rs#L13-L16, so why is the code trying to use it?