"Kevin O'Connor" <kevin@koconnor.net> wrote on 11/20/2015 11:12:53 AM:

>
> Hi Stefan,
>
> I've been reading through the tcgbios and tpm_drivers code in
> SeaBIOS.  I have a couple of questions:
>
> Why does the driver sometimes use tpm_sha1_calc() and sometimes use
> sha1()?  It seems the software sha1 implementation is always superior,
> so why bothering implementing the hardware version?  (The spec seems
> to agree with this as well.)  It seems like dropping tpm_sha1_calc()
> would simplify the code.

Ok, we can drop it.

>
> What is SCALAR in tpm_drivers() for - it seems like all the timeouts
> in the spec are increased by 10?  Also, it seems like tpm_drivers.c
> uses durations and timeouts in milliseconds, while
> tcgbios.c:determine_timeouts() uses values in microseconds.

The intention of doing this was so avoid timeouts.

>
> I don't understand the error handling in tpm_extend_acpi_log() and
> tpm_extend().  Why does a log overflow in tpm_extend_acpi_log()
> shutdown the tpm chip (via tpm_set_failure() )?  In particular,
> tpm_extend_acpi_log can be called from clients via the 16bit BIOS
> interface, and it's the only way a client could cause the tpm chip to
> shutdown.  Why does tpm_extend() call reset_acpi_log() on failure?  It
> seems odd that a failure in communication with the TPM chip would
> result in an ACPI log reset - no other TPM chip failure does that.

The intention here was to invalidate the log that is supposed to be written along with PCR extensions, resulting in attestation not being possible due to a failure in the extend.

>
> Is it expected that the tcpa ACPI table could move or be modified at
> runtime?  The code rescans for the table twice on every call to
> tpm_extend_acpi_log() - if it can't move or be modified then I think
> it would be simpler to cache the values.

I will have a look whether we can cache that. I guess for as long as it's scanned for 'early' we are not write-protected, yet. You may have seen I am also rescanning the log every time something is appended to it. Here the reason was that we are running in ROM mode and I cannot write to static variables anymore that would allow to set the pointer to the last entry. So back when I wrote this I handled the ACPI table in the same way - rescanning.

    Stefan

>
> -Kevin
>