Re: [SeaBIOS] [PATCH 00/10] Some TPM simplifications

[Kevin O'Connor]

On Tue, Jan 05, 2016 at 10:07:54PM -0500, Stefan Berger wrote:
> "Kevin O'Connor"  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

[PATCH 00/10] Some TPM simplifications

[Stefan Berger]

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