[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