"Kevin O'Connor" <kevin@koconnor.net> wrote on 01/05/2016 08:55:51 PM:

>
> On Tue, Jan 05, 2016 at 05:05:20PM -0500, Stefan Berger wrote:
> > "Kevin O'Connor" <kevin@koconnor.net> wrote on 01/05/2016 03:35:35 PM:
> [...]
> > > - Take "measurements" during the boot process so that later on users
> > >   can verify if some low-level code has changed (and thus attempt to
> > >   identify if malicious code may have been inserted into the
> > >   firmware).
> > >
> > >   - The major requirement here seems to be that if we can't take a
> > >     measurement that we either "cap" measurements or shutdown the TPM.
> > >     If we don't do this, it opens the possibility of a malicious
> > >     program forging measurements.
> >
> > That's correct. We don't cap the measurements but try to temporarily
> > deactivate the TPM until the next reboot.
> >
> > >
> > >   - It's also useful to skip taking measurements if the TPM device is
> > >     not present so that we don't waste CPU time taking measurements
> > >     that will never be used.
> >
> > Correct.
>
> 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?

>
> > > - Implement physical presence capability so that critical settings in
> > >   the TPM can only be changed by someone that can prove they are
> > >   physically present at the hardware (and thus attempt to prevent
> > >   malicious code that temporarily obtains escalated privileges from
> > >   altering these important settings).
> > >
> > >   - The major requirement here seems to be that the "physical
> > >     presence" lock always be set prior to starting the boot loader.
> >
> > Yes, we have to give up physical presence and lock that.
>
> Does deactivating also lock the physical presence?  The tpm_prepboot()
> code may not run if the tpm is in a "not working" state.
>

I just tested this and we need to send the two commands to give up physical
presence and lock it as well. I can send a patch for that tomorrow.

   Stefan

> -Kevin
>