[coreboot] Re: Measured boot and TPM standards
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 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_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 ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Reconsidering the Gerrit submission strategy
Hi everybody, I was recently made aware that Gerrit now supports adding metadata to commit messages in the "rebase" strategy. The "cherry-pick" strategy that we're using has been chosen over everything else primarily due to this capability. Some details: Gerrit supports different ways of committing changes into branches when developers submit them, with different effects on which changes are considered ready and how they show up in the commit history. The two main contenders are "cherry-pick" and "rebase always". Both create a linear history (unlike some "merge" strategies that can create merge commits. Both add metadata to the commits, all that "Reviewed-on", "Reviewed-by" etc in the commit message. Cherry-pick considers every change on Gerrit on its own. Even if you push a patch train of 50 commits, it allows submitting commit #49 individually. That gives some flexibility (if these commits are truly independent) but also creates risk: if changes are merged out of order, we might break the tree with otherwise perfectly good commits, for example when a new API is used that is only added by a previous commit. Rebase always considers patch trains: To submit commit #49, the commit itself and all its 48 ancestors need to be ready for submission. It becomes a one-click operation in the UI and ordering is honored. On the other hand, picking an individual commit is a manual operation now (cherry-pick to become its own patch train, push, re-review). Speaking of UI, depending on the strategy the "readiness" marker in the UI changes behavior, too: With "cherry-pick", each commit is compared against the branch individually, with a "merge conflict" notification if the commit on its own would fail to merge. With "rebase always" the entire patch train up to that point is considered. It's a matter of trade-offs, but given that "rebase always" can now add the metadata that was the deal breaker for anything but cherry-pick back in the day, I wanted to know how y'all feel about changing or keeping the submission strategy. David proposed that we could try out "rebase always" for a while (maybe a month) to see how it feels. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Liana Sebastian ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Measured boot and TPM standards
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
[coreboot] [coreboot - Bug #401] edk2 hangs indefiniately
Issue #401 has been updated by Arthur Heymans. Christian Walter wrote in #note-4: > Is this a problem within coreboot - or do we rather need to fix up EDKII ? The problem is inside EDKII. Those reverts would create problems for other payloads and Linux would even complain about incoherent MTRR settings I think. Bug #401: edk2 hangs indefiniately https://ticket.coreboot.org/issues/401#change-1044 * Author: Sean Rhodes * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: none * Start date: 2022-07-08 * Affected versions: master * Affected hardware: Everything * Affected OS: Doesn't matter Since CB:63555, edk2 will no longer boot and hangs indefiniately Various forks disable MTRR programming in edk2 (such as https://github.com/MrChromebox/edk2/commit/d641ea6920737fd9b9a94210e9a2e7636bfb3cdc) but this shouldn't be done as it breaks spec. Workarounds are to revert CB:64804, CB:63550, CB:64803 and CB:63555. ---Files with_avph_patch.txt (65.8 KB) with_avph_patch_reverted.txt (64.6 KB) master.txt (91.9 KB) master_w_revert.txt (197 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #401] edk2 hangs indefiniately
Issue #401 has been updated by Christian Walter. Is this a problem within coreboot - or do we rather need to fix up EDKII ? Bug #401: edk2 hangs indefiniately https://ticket.coreboot.org/issues/401#change-1043 * Author: Sean Rhodes * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: none * Start date: 2022-07-08 * Affected versions: master * Affected hardware: Everything * Affected OS: Doesn't matter Since CB:63555, edk2 will no longer boot and hangs indefiniately Various forks disable MTRR programming in edk2 (such as https://github.com/MrChromebox/edk2/commit/d641ea6920737fd9b9a94210e9a2e7636bfb3cdc) but this shouldn't be done as it breaks spec. Workarounds are to revert CB:64804, CB:63550, CB:64803 and CB:63555. ---Files with_avph_patch.txt (65.8 KB) with_avph_patch_reverted.txt (64.6 KB) master.txt (91.9 KB) master_w_revert.txt (197 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] [coreboot - Bug #401] edk2 hangs indefiniately
Issue #401 has been updated by Sean Rhodes. File master_w_revert.txt added File master.txt added Bug #401: edk2 hangs indefiniately https://ticket.coreboot.org/issues/401#change-1042 * Author: Sean Rhodes * Status: New * Priority: Normal * Assignee: Arthur Heymans * Category: board support * Target version: none * Start date: 2022-07-08 * Affected versions: master * Affected hardware: Everything * Affected OS: Doesn't matter Since CB:63555, edk2 will no longer boot and hangs indefiniately Various forks disable MTRR programming in edk2 (such as https://github.com/MrChromebox/edk2/commit/d641ea6920737fd9b9a94210e9a2e7636bfb3cdc) but this shouldn't be done as it breaks spec. Workarounds are to revert CB:64804, CB:63550, CB:64803 and CB:63555. ---Files with_avph_patch.txt (65.8 KB) with_avph_patch_reverted.txt (64.6 KB) master.txt (91.9 KB) master_w_revert.txt (197 KB) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
