On Tue, Jan 05, 2016 at 05:05:20PM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@koconnor.net wrote on 01/05/2016 03:35:35 PM:
[...]
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.
Then it sounds like the only time we need to call tpm_set_failure is on a failure of a TPM_ORD_Extend command. It might also make sense to deactivate the TPM if we detect the hardware but don't have the acpi tables present.
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.
Does deactivating also lock the physical presence? The tpm_prepboot() code may not run if the tpm is in a "not working" state.
-Kevin