A *measured boot* is by definition extending the PCR *before* running the measured code. However by only putting it into TCPA log it's no a measured boot at all.
Well, you're not doing that either, so I don't see why one of these implementations should somehow be allowed to call itself "measured boot" or considered compliant to some spec in a way the other isn't. Philipp's original implementation measures the bootblock and verstage long after they've started running already.
Maybe someone uses current measured boot in a slightly different manner than it used to be used in a pure VBOOT environment, without a strict RO partition in the flash and have a different way of ensuring the trust of the flash contents (I remember that eltan did something like this, see [1]). In this situation it is way more easier to ensure the integrity of just bootblock and verstage instead of checking all the stages.
I think our overall goal with adding security features to coreboot should be to have enough flexibility to support everyone's high-level use cases without making an unmaintainable mess of things. Right now the two trust models we support are essentially a) run VBOOT and write-protect RO_SECTION and b) don't run VBOOT and write-protect the whole CBFS. In both of these, as long as your bootblock is trusted your ramstage is guaranteed to be trusted as well, so I don't see the point of treating the two in any way different for measurement purposes.
It would be nice to support more models in the future (and I'm actively working on something that can chain trust from the bootblock through all stages to allow other trust anchors like BootGuard), but they need to be reasonably designed. I don't think "maybe someone trusts their verstage but not their ramstage" is a useful model -- I don't see how anything in coreboot currently supports that, and I can't think of a real scenario where that would be useful. Eltan is doing a bunch of weird stuff in their vendorcode but they're running their own measurement solution there anyway (and the point of vendorcode is also that vendors throw whatever they want in there but in return they can't expect the rest of the community to maintain it for them).
The fundamental problem is that we need to start measuring *somewhere*, and you will always have this issue that stages which came before that have to be backfilled somehow. Doing it in verstage doesn't really work because builds without CONFIG(VBOOT) don't have that stage. Bill tried writing code that puts it in the bootblock but that becomes a mess because many platforms are already at the very edge of what their bootblocks can fit and TPM drivers aren't small. ramstage is really the best spot for this -- we already have the TPM driver there anyway and there are the fewest size restrictions. In all the security models we support, you either cannot trust any part of coreboot (then even doing it in the bootblock is not good enough) or you are verified all the way through to ramstage and doing it there is just as secure as doing it earlier. It makes the design easier and I really don't see the downside.
To view, visit change 35077. To unsubscribe, or for help writing mail filters, visit settings.