On Tue, Jan 05, 2016 at 02:05:55PM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@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.
- 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.
- 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.
- 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. And, of course, we need to implement the ability to change the critical settings (via the tpm menu).
Does the above seem correct?
-Kevin
"Kevin O'Connor" kevin@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@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
-
Kevin O'Connor -
Stefan Berger