On Thu, Jan 07, 2016 at 05:08:53PM -0500, Stefan Berger wrote:
"Kevin O'Connor" kevin@koconnor.net 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 the
many
recent changes... Now my question is how to organize the code. Should
there
be one file where we essentially have the above type of code branching
into
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 patches 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 interpreted the spec as saying it should be possible to measure the memory at physical address zero (which is the interrupt descriptor table when in real mode). However, it does seem a bit silly.
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.
Okay.
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 device.
Okay.
-Kevin