On Tue, Feb 10, 2015 at 07:16:32AM -0500, Stefan Berger wrote:
On 02/09/2015 03:39 AM, Jarkko Sakkinen wrote:Thank you for the information. Do you think that for some reason
On Mon, Feb 09, 2015 at 12:08:46AM +0100, Peter Hüwe wrote:
Am Mittwoch, 4. Februar 2015, 15:21:09 schrieb Jarkko Sakkinen:I guess none of the TPM 1.2 command answer with the tag 0x8002?
If during transmission system error was returned, the logic was toIs it aware that some TPMs may respond with 0x00C1 as TAG for TPM1.2 commands?
incorrectly deduce that chip is a TPM 1.x chip. This patch fixes this
issue. Also, this patch changes probing so that message tag is used as the
measure for TPM 2.x, which should be much more stable.
FYI: pdf page 26 , section 6.1 explains the predictable return value for a
TPM1.2 command seen by a TPM2
http://www.trustedcomputinggroup.org/files/static_page_files/8C68ADA8-1A4B-B294-D0FC06D3773F7DAA/TPM%20Rev%202.0%20Part%203%20-%20Commands%2001.16-code.pdf
Following this:
Sending a TPM1.2 command to a TPM2 should return a TPM1.2 header (tag =
0xc4) and error code (TPM_BADTAG = 0x1e)
Sending a TPM 2 command to a TPM 2 will give a TPM 2 tag in the header.
Sending a TPM 2 command to a TPM 1.2 will give a TPM 1.2 tag in the header
and an error code.
tpm2_probe() shoould instead check that value is not this error
instead of checking that tag is 0x80002?