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

[Stefan Berger]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.seabios.org/pipermail/seabios/attachments/20160106/3ac8ac12/attachment.html>