On Tue, Jan 05, 2016 at 10:07:54PM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@koconnor.net wrote on 01/05/2016 08:55:51 PM:
Then it sounds like the only time we need to call tpm_set_failure is on a failure of a TPM_ORD_Extend command. It might also make sense to deactivate the TPM if we detect the hardware but don't have the acpi tables present.
I would also deactivate it if it returned an error to TPM_ORD_Startup, TPM_ORD_SelfTestFull. Since the menu is written in such a way that the user only has the choices that are valid for the current state, also those commands have to work, unless the TPM is defective. Or is that too strict?
Attempting to deactivate if TPM_ORD_Startup or TPM_ORD_SelfTestFull fail makes sense.
I wonder if the code could attempt to assert physical presence in tpm_startup() and only enable the tpm menu if that succeeds.
BTW, if I'm reading the specs correctly, CMD_ENABLE is likely to fail on real hardware as manufacturers are supposed to set LifetimeLock at the factory. It also appears that CMD_ENABLE alters non volatile memory, so writing it on every boot may cause wear on the device?
-Kevin