"Kevin O'Connor" <kevin@koconnor.net> wrote on 01/05/2016 11:03:00 PM:

>
> 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.

There are two ways to assert physical presence, one is via software, the other via hardware.

For hardware assertion there's a PIN on the chip that indicates the state of a dip switch
for example. Problem is, this assertion cannot easily be read as a flag. We have to infer this
via a command. So the trick seems to be to send TPM_PhysicalEnable/TPM_PhysicalDisable
with the value that's already there.

The software assertion can be done, unless prevented, the way we do it now.

>
> 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

I'll try to rework that.

   Stefan

> memory, so writing it on every boot may cause wear on the device?
>
> -Kevin
>