[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Michał Żygowski. There may not be a strong need to have multiple hashes in the log entries yet. I have also recently spotted Intel fTPMs that can have only one PCR bank active at a time, so only discrete TPMs are capable of having multiple PCR banks active.

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Julius Werner. > However, instead of following existing standards, be it TCG or coreboot, such > approach creates yet another one. Having the ability to use more than one > would make transition to TPM2.0 easier, if not no-op. Since we are going to > have to

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Krystian Hebel. > I don't know what skiboot is... is that coreboot? Do they have a real use > case for having both hashes in the log or is it just another bootloader where > someone decided "might as well write all the hashes in advance just because > the spec

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Julius Werner. > It would actually simplify the API by making parameter lists shorter and > input data better grouped. Having to construct a separate parameter struct rather than just throwing in two scalars is not "simpler". > `skiboot` writes both SHA1 and

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Sergii Dmytruk. Julius Werner wrote in #note-10: > I still feel strongly that we shouldn't overcomplicate APIs It would actually simplify the API by making parameter lists shorter and input data better grouped. > increase maintenance burden by implementing

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Julius Werner. > I think we might as well implement agile format properly (no fixed-size > buffers in structures, any number of algorithms) right away. You are implementing the format properly (the format defines how the TCPA log is supposed to look in memory,

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Sergii Dmytruk. Julius Werner wrote in #note-8: > are you planning to make a bunch of Kconfigs to select this vboot2 supports 4 matching hashes, so 4 corresponding options. > Basically, I understand that the log format *allows* multiple algorithms, and > that's

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Julius Werner. > > Can you explain what use case you have that requires you to use multiple > > algorithms? > > This allows for greater flexibility, where multiple coexisting programs may > have different expectations, e.g. one is old enough to not know anything

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Krystian Hebel. Julius Werner wrote in #note-4: > Can you explain what use case you have that requires you to use multiple > algorithms? This allows for greater flexibility, where multiple coexisting programs may have different expectations, e.g. one is old

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Sergii Dmytruk. Sergii Dmytruk wrote in #note-5: > `tpm_extend_pcr()` would be updated for consistency here, but it's not > strictly necessary. Correction: `tpm_extend_pcr()` can invoke `tcpa_log_add_table_entry()` in its body, so it should have a similar

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Sergii Dmytruk. > Can you explain what use case you have that requires you to use multiple > algorithms? I'll let Krystian and Michał correct me, but I'm not sure if we have an actual need for multiple algorithms right away. The API change is probably

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Julius Werner. Can you explain what use case you have that requires you to use multiple algorithms? And why is it not enough to just call tpm_extend_pcr() several times, once for each algorithm? Let's clarify what your high-level goal here is first before we

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Sergii Dmytruk. If there are no objections, I'll use an API like this instead: ``` struct tpm_digest { const uint8_t *hash; size_t len; enum vb2_hash_algorithm hash_type; }; /** * Ask vboot for a digest and extend a TPM PCR with it. *

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Michał Żygowski. Parent task set to #420 Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421#change-1175 * Author: Krystian Hebel * Status: New * Priority:

[coreboot] [coreboot - Cleanup #421] Change API of functions taking hash as an argument

Issue #421 has been updated by Michał Żygowski. Related to Feature #420: Use standard format of TPM event log added Cleanup #421: Change API of functions taking hash as an argument https://ticket.coreboot.org/issues/421#change-1163 * Author: