Patrick Georgi has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35077 )
Change subject: security/vboot: Decouple measured boot from verified boot ......................................................................
Patch Set 70:
Patch Set 70:
Now we are back at tcpa log replay. Not gonna happen. It impacts the security of a measured boot
So I've read through the discussion, and while there are a few potential security issues that I could imagine with TCPA log replay, I don't see how the very same issues wouldn't apply to the retroactive measuring that we have now.
So how is the replay approach worse than what we have right now? And, if it is a problem, isn't the proper solution to push tpm init earlier - which, in the replay case, seems to automatically solve any issues because any further measurement is done at the time the stage is loaded? Which is the same approach I'd take to close any gaps in the current retroactive measuring scheme.
From my point of view these two approaches seem to be equivalent in impact, with the major difference being a code design improvement by the change (as claimed by Julius, I haven't looked at the big design picture yet), so what's the problem with this change?
It's possible that I missed something big (as said I haven't gone through the entire design here, just the question of when measurements happen and from which data source), but if the TCPA log stored in (CAR) memory isn't trustworthy from bootblock to romstage, any assurance that measurements are worth anything is bound to go down the drain, no?
One thing that could be negatively affected is compliance to some bullshit firmware security standard, but even NIST SP 800-147 and SP 800-155 don't seem to say anything about how measuring is supposed to happen. 155 mentions the word "replay", but in a very specific context that doesn't apply here ("not just a replay of an earlier good response"). If it helps, we could probably call the early TCPA log a "PCR cache"?