On Sun, 14 Dec 2014, Stefan Berger wrote:
On 12/14/2014 10:40 AM, Jarkko Sakkinen wrote:One system's output, with a dev_info call to show the value of rc:
On Sun, Dec 14, 2014 at 09:48:26AM -0500, Stefan Berger wrote:You are now calling tpm2_gen_interrupt and are looking at the rc, which is the
On 12/12/2014 02:46 PM, Jarkko Sakkinen wrote:I propose this: lets keep the bit ugly but approach for now and when
Detect TPM 2.0 by sending idempotent TPM 2.x command. Ordinals forTPM TIS 1.2 can report either 0xff or 0x00 for sts3 since that part of
TPM 2.0 are higher than TPM 1.x commands so this should be fail-safe.
Using STS3 is unreliable because some chips just report 0xff and not
what the spec says.
register was not defined for this version but only for a later version.
unless the TIS 1.3 for TPM 2.0 is broken, it should report a bit _pattern_
(not plain 0x00 or 0xff) that you could apply the suggested mask to and
there are TPM2 FIFOs available in the market move to your workaround.
I think that would be the most reasonable middle road here.
rc from tpm_transmit_cmd, which seems to make sure that the sending of the
command went alright and the reception of the response. Is this good enough to
distinguish between a TPM 2 and a TPM 1.2? If you send a valid TPM 2 command
to a TPM 1.2 this will at least transmit the data ok, but the TPM will respond
with a TPM 1.2 tag in the response. The way I understand the code, the rc does
not include whether the response packet is a valid TPM 2 response packet and
lets you conclude to a TPM2. I do something similar in upcoming QEMU patches
where I send a valid TPM2 command for probing and if the tag(!) in the
response is a TPM2 tag (0x8001 = TPM_ST_NO_SESSIONS), then it's a TPM 2,
otherwise a TPM 1.2.
Did you test this with a TPM 1.2 ?
[ 0.223837] tpm_tis 00:08: tpm2_gen_interrupt(chip, true) -> 0xa
[ 0.223847] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[ 0.280468] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, polling instead