<tt><font size=2>"Kevin O'Connor" <kevin@koconnor.net>
wrote on 11/20/2015 11:12:53 AM:<br></font></tt><br><tt><font size=2>> <br>> Hi Stefan,<br>> <br>> I've been reading through the tcgbios and tpm_drivers code in<br>> SeaBIOS.  I have a couple of questions:<br>> <br>> Why does the driver sometimes use tpm_sha1_calc() and sometimes use<br>> sha1()?  It seems the software sha1 implementation is always
superior,<br>> so why bothering implementing the hardware version?  (The spec
seems<br>> to agree with this as well.)  It seems like dropping tpm_sha1_calc()<br>> would simplify the code.</font></tt><br><br><tt><font size=2>Ok, we can drop it.</font></tt><br><tt><font size=2><br>> <br>> What is SCALAR in tpm_drivers() for - it seems like all the timeouts<br>> in the spec are increased by 10?  Also, it seems like tpm_drivers.c<br>> uses durations and timeouts in milliseconds, while<br>> tcgbios.c:determine_timeouts() uses values in microseconds.</font></tt><br><br><tt><font size=2>The intention of doing this was so avoid timeouts.</font></tt><br><tt><font size=2><br>> <br>> I don't understand the error handling in tpm_extend_acpi_log() and<br>> tpm_extend().  Why does a log overflow in tpm_extend_acpi_log()<br>> shutdown the tpm chip (via tpm_set_failure() )?  In particular,<br>> tpm_extend_acpi_log can be called from clients via the 16bit BIOS<br>> interface, and it's the only way a client could cause the tpm chip
to<br>> shutdown.  Why does tpm_extend() call reset_acpi_log() on failure?
 It<br>> seems odd that a failure in communication with the TPM chip would<br>> result in an ACPI log reset - no other TPM chip failure does that.</font></tt><br><br><tt><font size=2>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.</font></tt><br><tt><font size=2><br>> <br>> Is it expected that the tcpa ACPI table could move or be modified
at<br>> runtime?  The code rescans for the table twice on every call
to<br>> tpm_extend_acpi_log() - if it can't move or be modified then I think<br>> it would be simpler to cache the values.</font></tt><br><br><tt><font size=2>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.</font></tt><br><br><tt><font size=2>    Stefan</font></tt><br><tt><font size=2><br>> <br>> -Kevin<br>> <br></font></tt><BR>