On Thu, 2019-09-26 at 16:12 +0300, Jarkko Sakkinen wrote: > On Thu, Sep 26, 2019 at 03:46:35PM +0300, Jarkko Sakkinen wrote: > > On Wed, Sep 25, 2019 at 04:48:41PM +0300, Jarkko Sakkinen wrote: > > > - tpm_buf_reset(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_RANDOM); > > > + tpm_buf_reset(&buf, data_ptr, PAGE_SIZE, > > > + TPM2_ST_NO_SESSIONS, TPM2_CC_PCR_EXTEND); > > > > Oops. > > Maybe we could use random as the probe for TPM version since we anyway > send a TPM command as a probe for TPM version: > > 1. Try TPM2 get random. > 2. If fail, try TPM1 get random. > 3. Output random number to klog. > > Something like 8 bytes would be sufficient. This would make sure that > no new change breaks tpm_get_random() and also this would give some > feedback that TPM is at least somewhat working. That involves sending 2 TPM commands. At what point does this occur? On registration? Whenever getting a random number? Is the result cached in chip->flags? Will this delay the TPM initialization, causing IMA to go into "TPM bypass mode"? Mimi
