<tt><font size=2>"Kevin O'Connor" <kevin@koconnor.net>
wrote on 01/05/2016 08:55:51 PM:<br><br>> <br>> On Tue, Jan 05, 2016 at 05:05:20PM -0500, Stefan Berger wrote:<br>> > "Kevin O'Connor" <kevin@koconnor.net> wrote on
01/05/2016 03:35:35 PM:<br>> [...]<br>> > > - Take "measurements" during the boot process
so that later on users<br>> > >   can verify if some low-level code has changed (and
thus attempt to<br>> > >   identify if malicious code may have been inserted
into the<br>> > >   firmware).<br>> > > <br>> > >   - The major requirement here seems to be that if
we can't take a<br>> > >     measurement that we either "cap"
measurements or shutdown the TPM.<br>> > >     If we don't do this, it opens the possibility
of a malicious<br>> > >     program forging measurements.<br>> > <br>> > That's correct. We don't cap the measurements but try to temporarily<br>> > deactivate the TPM until the next reboot.</font></tt><br><tt><font size=2>> > <br>> > > <br>> > >   - It's also useful to skip taking measurements if
the TPM device is<br>> > >     not present so that we don't waste CPU time
taking measurements<br>> > >     that will never be used.<br>> > <br>> > Correct.<br>> <br>> Then it sounds like the only time we need to call tpm_set_failure
is<br>> on a failure of a TPM_ORD_Extend command.  It might also make
sense to<br>> deactivate the TPM if we detect the hardware but don't have the acpi<br>> tables present.</font></tt><br><br><tt><font size=2>I would also deactivate it if it returned an error
to TPM_ORD_Startup, TPM_ORD_SelfTestFull.</font></tt><br><tt><font size=2>Since the menu is written in such a way that the user
only has the choices that are valid</font></tt><br><tt><font size=2>for the current state, also those commands have to
work, unless the TPM is defective. Or is</font></tt><br><tt><font size=2>that too strict?</font></tt><br><tt><font size=2><br>> <br>> > > - Implement physical presence capability so that critical
settings in<br>> > >   the TPM can only be changed by someone that can prove
they are<br>> > >   physically present at the hardware (and thus attempt
to prevent<br>> > >   malicious code that temporarily obtains escalated
privileges from<br>> > >   altering these important settings).<br>> > > <br>> > >   - The major requirement here seems to be that the
"physical<br>> > >     presence" lock always be set prior to
starting the boot loader.<br>> > <br>> > Yes, we have to give up physical presence and lock that.<br>> <br>> Does deactivating also lock the physical presence?  The tpm_prepboot()<br>> code may not run if the tpm is in a "not working" state.<br>> </font></tt><br><br><tt><font size=2>I just tested this and we need to send the two commands
to give up physical</font></tt><br><tt><font size=2>presence and lock it as well. I can send a patch for
that tomorrow.</font></tt><br><br><tt><font size=2>   Stefan</font></tt><br><tt><font size=2><br>> -Kevin<br>> <br></font></tt><BR>