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_v23_pub.pdf
[VBOOT]
https://doc.coreboot.org/security/vboot/measured_boot.html#tcpa-eventlog
[TPM12]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf
[LINUX]
https://github.com/torvalds/linux/blob/master/drivers/char/tpm/eventlog/acpi.c#L105
[DRTM]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture_v1-0_Published_06172013.pdf
--
Krystian Hebel
Firmware Engineer
https://3mdeb.com | @3mdeb_com
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
