"Kevin O'Connor" kevin@koconnor.net wrote on 01/08/2016 11:41:13 AM:
On Thu, Jan 07, 2016 at 03:39:13PM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@koconnor.net wrote on 01/07/2016 03:14:37 PM:
I don't have input on what TPM2 organization should look like,
mainly
because I don't know what TPM2 entails. I gather the TIS commands
are
changing, but what else changes? Does the ACPI log, BIOS interface, or tpm menu change? Do you have a pointer to the TPM2 spec (when I last looked it seemed that TPM2 was still being worked on).
The TIS got more registers; some flags allow detection of the TPM
version.
All commands changed -- no backwards compatibility. The header
'fields'
are the same, their ordinal and tag values are not.
Spec:
http://www.trustedcomputinggroup.org/resources/tpm_library_specification
Thanks. Does the hardware interface change as well (ie, is it still the same reads/writes to MMIO at 0xfed40000)?
It has the same address, but one or two more registers.
My initial thought would be to do what you've proposed - have wrapper functions around the TPM commands (eg, tpm_extend, tpm_get_capability, read_permanent_flags) and teach those functions how to send the two different styles of commands (and translate the responses if necessary).
So the good thing is that some of the code can be shared between 1.2 and 2.0, to a certain 'depth' at least. An example of a shared function would be this one.
static void tpm_add_event_separators(void) { static const u8 evt_separator[] = {0xff,0xff,0xff,0xff}; u32 pcrIndex; for (pcrIndex = 0; pcrIndex <= 7; pcrIndex++) tpm_add_measurement_to_log(pcrIndex, EV_SEPARATOR, NULL, 0, evt_separator, sizeof(evt_separator)); }
Following this function further down:
tpm_add_measurement_to_log() [on current master] can be completely shared as well. tpm_log_extend_event would need to become a function that branches into tpm12_log_extend_event and tpm2_log_extend_event, depending on detected version of TPM.
tpm_log_event could again be shared since ACPI logging is the same. Same for tpm_fill_hash for as long as we only support sha1.
Basically all functions where commands are created cannot be shared. Also TPM 2's initialization is a bit different and it supports more hashes.
So it actually speaks against splitting this up into different files, but the outcome may be that the code would show a mix of tpm12_*, tpm2_*, and tpm_* functions in the format of
tpm12_foo() { [...] }
tpm2_foo() { [...] }
tpm_foo() { switch (tpmversion) { 1.2: return tpm12_foo() 2: return tpm2_foo() } }
tpm_xyz() { [...] }
tpm12_bar() { [...] }
tpm2_bar() { [...] }
[...]
That's what I did before...
If none of the code could be shared the decision to split it up completely would be a lot easier.
Stefan
-Kevin