[SeaBIOS] [PATCH 00/10] Some TPM simplifications
Stefan Berger
stefanb at us.ibm.com
Tue Jan 5 23:05:20 CET 2016
"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>
More information about the SeaBIOS
mailing list