On Tue, Jan 05, 2016 at 10:07:54PM -0500, Stefan Berger wrote: > "Kevin O'Connor" <ke...@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 _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
