"Kevin O'Connor" <ke...@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" <ke...@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 >
_______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios