This was just brought up in the biweekly meeting but it seemed like none of us there really knew why +Philipp implemented it this way. My guess(?) would be that they tried to follow the TPM 1.2 standard, but maybe some mistakes crept in, and then I guess that code was just reused for TPM 2.0 cases which maybe wasn't the right thing to do. I don't know if he or 9elements have any specific reason to stick with the existing format.
vboot itself isn't really involved with this... it provides some of the low-level hashing and TPM access routines but the code defining the TCPA format is separate. We do have that feature that PCR0 and PCR1 are used to log some vboot-specific data, and we'd like to keep that option available since we're using it for Chrome OS, but I'm fine with making it configurable if other platforms want to use these PCRs for their TCG standard uses instead.
On Wed, Jul 13, 2022 at 9:29 AM Krystian Hebel krystian.hebel@3mdeb.com wrote:
TL;DR: why doesn't vboot follow existing standards and tries to create its own instead? [XKCD]
During our adventures with enabling coreboot port for Talos 2 we got to the point of enabling TPM, and with it, measured boot. coreboot's part worked without too many issues other than those resulting from assumptions about endianness, Skiboot's (payload) - not so much, at least it seemed that way. Hardware access worked after adding a driver implementation for new module, but it failed to parse event log and in result disabled TPM.
Skiboot (payload) expects Agile format [TPM20] of event log, while vboot provides its own format [VBOOT], compatible with neither Agile nor legacy format used by TPM 1.2 [TPM12]. Even worse, address of this log is written to TCPA ACPI table, from which it is read and parsed (or at least tried) by kernel as TPM 1.2 format [LINUX].
At first I thought custom format was developed to add support for SHA-256, but only TPM 2.0 uses it, and it already has new format, capable of storing bigger hashes. Which brings up the question: why use own format that nothing else knows how to parse? Are there any reasons against switching to Agile format? AFAICT only cbmem can parse the current form.
Another problem is PCR assignments: on one hand, [VBOOT] says that "coreboot uses the SHA-1 or SHA-256 hash algorithm depending on the _TPM specification_ for measurements", and then doesn't follow any existing specification, even though both families have predefined and mostly compatible with each other uses for PCRs (section 3.3.3 in [TPM12] and 3.3.4 in [TPM20]). Measuring GBB flags to PCR0 is dubious since PCR0 is usually used for code at or near RTM.
Speaking of RTM, what the heck with those SRTM/DRTM definitions? When reading it, I got the feeling that there was misunderstanding and someone thought that S stands for software, D - discrete, although expansions of those abbreviations in the vboot documentation are correct. [DRTM] definitely isn't able to start from IBB, as is suggested in that documentation.
We would like to work on mentioned issues, both implementation and documentation. Before we invest time in it, we would like to know whether there are any reasons that would require keeping current form, any caveats or design decisions we've missed.
[XKCD] https://xkcd.com/927/ [TPM20] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_... [VBOOT] https://doc.coreboot.org/security/vboot/measured_boot.html#tcpa-eventlog [TPM12] https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementat... [LINUX] https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/acpi... [DRTM] https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture_...
-- Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org