On 07/28/2016 12:54 PM, Kevin O'Connor wrote:
On Tue, Jul 26, 2016 at 11:19:50AM -0400, Stefan Berger wrote:
> Extend the tpm20_extend function to support extending a hash to
> multiple PCR banks. The sha1 hash that's being extended into the
> sha256 bank for example, will be filled with zero-bytes to the
> size of a sha256 hash.
> + * Write the TPM2 tpml_digest_values data structure from the given hash.
> + * Follow the PCR bank configuration of the TPM and write the same hash
> + * in either truncated or zero-padded form in the areas of all the other
> + * hashes. For example, write the sha1 hash in the area of the sha256
> + * hash and fill the remaining bytes with zeros. Or truncate the sha256
> + * hash when writing it in the area of the sha1 hash.
> + *
> + * dest: destination buffer to write into; if NULL, nothing is written
> + * destlen: length of destination buffer
> + * pcrindex: the PCR index
> + * hash: the hash value to write
> + * hashAlg: the hash alogorithm determining the size of the hash
> + * count: pointer to a counter for how many entries were writte
> + *
> + * Returns the number of bytes needed in the buffer; -1 on fatal error
> + */
> +static int
> +tpm20_write_tpml_dig_values(u8 *dest, size_t destlen, u32 pcrindex,
> + const u8 *hash, u16 hashAlg)
So, if I understand this correctly, the current code creates a
"digest" with just a sha1 hash. However, the hardware has a
description of what the digest should look like, and this patch takes
the current digest and produces the digest format desired by the
hardware. Patch 6 does the same for the log.
The TPM 2 supports multiple PCR banks with SHA1 , SHA256, SHA384 etc.
Multiple of these banks can be active at the same time. To avoid abuse
of these banks during attestation (filling them with bogus values and
then quoting), we want to use all banks. Since we don't support hashing
the data will all these different hashes at the same time, we would use
the SHA 1 digest of the data for extension in the SHA256 bank etc.
If so, could the code instead build the digest according to the
hardware description instead of trying to reformat it after it is
built? Specifically, the only callers of tpm_extend() and
tpm_log_event() produce a 'struct tcg_pcr_event2_sha1' with the digest
in the simple hash format - could these locations create
tcg_pcr_event2_sha1 in the desired hardware specified format initially
and thus avoid needing to reformat that digest?
Yes, that would also be possible.
> + if (dest && offset > destlen)
> + panic("buffer for tpml_digest_values is too small\n");
panic() should be avoided. On real hardware if the BIOS were to
panic() it could effectively brick the machine.
Assuming I calculated the size correct, this error should never happen.
So I have to remove this error report altogether or can I convert it
into a print statement? I introduced this since I am not calculating the
buffer size anymore...