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.
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.
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.
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.
-Kevin
"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
-
Kevin O'Connor -
Stefan Berger