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

[Stefan Berger]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.seabios.org/pipermail/seabios/attachments/20160105/0b3a8521/attachment-0001.html>