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

Kevin O'Connor kevin at koconnor.net
Wed Jan 6 02:55:51 CET 2016


On Tue, Jan 05, 2016 at 05:05:20PM -0500, Stefan Berger wrote:
> "Kevin O'Connor" <kevin at 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.

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

-Kevin



More information about the SeaBIOS mailing list