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