"Kevin O'Connor" <kevin@koconnor.net> wrote on 01/06/2016 12:47:29 PM:


>
> On Wed, Jan 06, 2016 at 11:55:19AM -0500, Stefan Berger wrote:
> > "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.
>
> I should have said, "I wonder if the code could check if software
> physical presence has been enabled in tpm_startup() and only enable
> the tpm menu if that succeeds".  That is, could we issue a

I understood it that way.

> TPM_ORD_PhysicalPresence(NOT_PRESENT) and if it succeeds then we
> enable the menu and make sure we always issue a LOCK before booting.

What I am doing now in assert_physical_presence is to check whether
physical presence has already been asserted and return 0, check
whether HW physical presence has been asserted and return 0, if SW
assertion has been disabled return -1, otherwise try to do SW assertion.

We need to issue TPM_ORD_PhysicalPresence(PRESENT) to assert SW pp and
TPM_ORD_PhysicalPresence(NOT_PRESENT + LOCK) in tpm_prepboot.

tpm_prepboot actually needs to be further adapted for the case of HW pp. Probably
it is not necessary to send the CMD_ENABLE in any case. I forgot about that
in the patches I sent.


> If the command fails then the code assumes it has no requirements wrt
> physical presence.
>
> If that's too restrictive, could the startup code query if either
> CMD_ENABLE has already been set or if LifetimeLock has not been set?

Have a look at the patch I sent. I think this correct extends to assert_physical_presence
function with making sure that SW pp is asserted or HW pp is asserted through other means.

>
> > 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.
>
> Is there any BIOS requirements when hardware physical presence is in
> use though?  If the hardware physical presence is set, then the BIOS
> can't limit the owner/activate/enable commands.  So, why bother with
> the tpm menu - the user could just administer those settings from the
> OS.

In my opinion HW pp should also allow the menu to be presented so
that users do not need different tools in OS that normally are not available
due to SW pp. Though no command seems to be able to overrid the HW physical
presence.

   Stefan

>
> -Kevin
>