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

>
> On Tue, Jan 05, 2016 at 02:05:55PM -0500, Stefan Berger wrote:
> > "Kevin O'Connor" <kevin@koconnor.net> wrote on 01/05/2016 12:16:18 PM:
> > > On Tue, Dec 29, 2015 at 07:17:40PM -0500, Kevin O'Connor wrote:
> > > > The following series involves some code reorganization in the TPM code
> > > > that I found useful in understanding the code.
> > >
> > > FYI, I committed patches 1-9 (after some bug fixes).
> >
> > The result of the 2nd patch set also looks good.
>
> Thanks - I pushed most of that series as well.
>
> I've been looking further at error recovery in the TPM code.  I'm not
> sure I fully understand what needs to be done on an error.
>
> If I understand it correctly, the SeaBIOS TPM code has three major
> requirements:
>
> - Pass through commands from the 16bit bios interface to the TPM.
>   This is useful for bootloaders/oproms that don't have a TPM driver.
>
>   - I think the only requirement for error recovery here is that we
>     return an appropriate error code to the caller of the 16bit BIOS
>     interface.

Once we leave the BIOS and enter trusted grub bootloader for example, we have
given up physical presence. So certain functionality is not available anymore
and calling tpm_set_failure() actually will not be able to deactivate the TPM
anymore. That said, whatever happens in terms of TPM failures that trusted grub
may encounter would have to be handled differently. I do not remember
having read something about theses cases in the specs, though the possibilty
would exist to extend and / or log a special value.


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

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

>     And, of course, we need to implement the ability to change the
>     critical settings (via the tpm menu).
>
> Does the above seem correct?

This sounds correct.

Capping actually is mentioned in the spec for certain error conditions where the value 01h
is supposed to be measured into PCR[0-7]. I don't read about logging these, though.

   Stefan


>
> -Kevin
>