"Kevin O'Connor" <firstname.lastname@example.org>
wrote on 01/07/2016 03:14:37 PM:
> On Thu, Jan 07, 2016 at 01:57:42PM -0500, Stefan Berger wrote:
> > At some point I'll bring the TPM 2 patches back to life following
> > recent changes... Now my question is how to organize the code.
> > be one file where we essentially have the above type of code
> > TPM 1.2 & TPM 2 specific functions and TPM 1.2 and TPM 2
code in separate
> > files or the above type of functions at the end of the current
file and then
> > a section with TPM 1.2 code and another with TPM 2? It's a few
> > building on top of each other, so want to avoid churn...
> I was playing with a few additional patches on top of your last series
> - I pushed them to my testing branch if you want to take a look.
I found this:
if (hashdata || hashdata_length)
it should probably be:
if (hashdata && hashdata_length)
But now I am arguing against the spec. They want 0
bytes to be 'measured'?
I would also shut down the TPM if an extend didn't
work; after all the TPM will
'quote' the state of the PCRs in an attestation. By
temporarily deactivating it,
it will not be able to quote anymore. Though that
type of failure should never occur.
I am not sure about a failed getcapability whether
it's right or wrong to shut
down the TPM. Basically this should never happen,
either. I would tend to shut it down
based on the fact that something is wrong with the
> 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
> 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
> last looked it seemed that TPM2 was still being worked on).