FMC/ROM PCR handling discrepancies

[FerralCoder]

In updating the FMC documentation, I noticed some problems with how we are dealing with PCRs that needs to be clarified and/or fixed in both the documentation and the implementation.

First, it looks like ROM is only updating a single PCR now. I seem to remember some discussions a while back about no longer needing both Current and Journey, but I forget the conclusion of that. Maybe we only need Current now? The ROM documentation/code comments do not seem to be in sync to definitively answer that question. The top level Caliptra spec also still talks about using both Current/Journey registers, and has FMC and ROM updating the same registers instead of the dedicated registers we moved to (only table 9 shows them using different banks).

FMC is still updating both a Current and Journey PCR, expected flow as follows: • PCR 2 – Journey • PCR 3 – Current • FMC clears Current PCR at start of flow (not Journey) • FMC extends both PCRs with RT/Manifest measurements • FMC locks both registers

Problem – Journey PCR will not make sense. On first cold boot it will be fine. But after say a warm reset, we will incorrectly extend it again with the same value. Current will have a valid value but Journey will not. Possible solution – FMC must go back to detecting reset type. Skip updating Journey on Warm reset (still update on Cold or Update). Of course this is moot if we no longer need the Journey register.

Overall, I think this shows we need a more thorough review of all of our PCR usage and documentation to make sure we are consistent and correct.

[rusty1968]

@bluegate010

[bluegate010]

@rusty1968 and I met briefly to discuss. Having ROM not measure into PCR1 was seen as an optimization, since FMC does not get hitlessly updated. That being said, there's an argument for consistency here, having a journey and current PCR for FMC just as we have a pair of them for RT FW. Verifiers could choose whether to pay attention to PCR1 or whether to look only at PCR0 - either PCR should be able to convey the relevant measurements.

[FerralCoder]

@mhatrevi @jhand2

[jhand2]

I think for the RT journey PCR (PCR 2), +1 to only extending it on cold and update reset (not warm reset). On warm reset, FMC would still lock both PCRs.

I think it still makes sense to keep the current & journey for RT to track hitless updates.

[FerralCoder]

I agree with the update above from @bluegate010 that it is not important for ROM to update a Journey PCR for FMC. But whether we do or not, the specs need to be updated to reflect the way this has been implemented.

Aside from that, I am still concerned that as currently designed, the journey PCR updated by FMC to reflect RT may not operate as intended. Since FMC does not distinguish between reset types and always performs the same flows, Journey will be correctly extended on a Cold Reset or an Update Reset. However, if a Warm Reset occurs, the Journey PCR will be extended with an additional measurement of the same RT module that was there for the previous boot. Now the PCR value will be unexpected because the PCR has now been extended twice (or more) with the same RT measurement.

Is this OK? I presume it is not and we must add complexity to FMC to detect reset type and skip extending Journey on the Warm Reset case. Does anyone else see this differently?

[varuns-nvidia]

+1 to not extending on a Warm Reset.

[rusty1968]

FMC will be modified to detect reset type and skip extending Journey on the warm reset case.

[bluegate010]

https://github.com/chipsalliance/caliptra-sw/pull/482 attempts to unify the PCR handling logic between ROM and FMC.

[rusty1968]

477 addressed the FMC logic and has been merged, Thanks @bluegate010 for reviewing.

Issue #506 documents the follow up to test the FMC PCR extension logic.

[FerralCoder]

All items in this issue have been addressed by previous commits except for the main spec. Created a separate issue to track that: https://github.com/chipsalliance/Caliptra/issues/87