Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

OPTIGA™ TPM Forum Discussions

AleCla97
Level 1
Level 1
First reply posted 5 sign-ins First question asked

Hi, I have integrated the TPM 2.0 Iridium SLB 9670 together with the i.MX8MP processor to implement remote attestation using the IMA Linux kernel module. Sometimes I get strange this error "tpm tpm0: invalid TPM_STS.x 0xa8 " that I cannot find a solution online. As I understand it I should get 0xff in case there are transmission calls to tpm that are not protected by the tpm_try_get_ops command. Checking the Linux kernel however it is indeed called and in fact, the value is not 0xff but is variable. On a couple of other occasions, however, it has failed to even establish the initial connection ('2.0 TPM (device-id 0x1B, rev-id 22') and some debugging showed that the tpm spi driver was stuck in an infinite loop waiting for the TPM locality. The wiring is correct, in fact, if the tpm connects without errors, the tpm2tools commands work. The device tree is correct because I asked for confirmation on the NXP forum. I also tried replacing the tpm but got the same result. I currently I'm using Linux kernel 5.15.60 but I get the same error using the i.MX6UL board which has kernel 5.10.60. What caused this error?

The output of dmesg | grep -i tpm

[ 2.077539] tpm_tis_spi spi1.0: 2.0 TPM (device-id 0x1B, rev-id 22)

[ 2.088911] tpm tpm0: A TPM error (256) occurred attempting the self test

[ 2.095719] tpm tpm0: starting up the TPM manually

[ 12.489312] tpm tpm0: tpm_try_transmit: send(): error -5

[ 38.235405] tpm tpm0: tpm_transmit: tpm_recv: error -52

[ 38.284794] tpm tpm0: invalid TPM_STS.x 0x85, dumping stack for forensics

[ 38.284861] tpm_tis_status+0xc8/0xe4

[ 38.284869] wait_for_tpm_stat+0x54/0x224

[ 38.284878] tpm_tis_send_data+0x220/0x28c

[ 38.284886] tpm_tis_send_main+0x34/0x110

[ 38.284893] tpm_tis_send+0x44/0x110

[ 38.284901] tpm_transmit+0xc8/0x340

[ 38.284908] tpm_transmit_cmd+0x30/0xc0

[ 38.284914] tpm2_pcr_extend+0x25c/0x300

[ 38.284921] tpm_pcr_extend+0xc4/0xd4

0 Likes
2 Replies
snehapra
Moderator
Moderator
Moderator
100 replies posted 25 likes received 100 sign-ins

Hi @AleCla97 ,

Sorry for the late response, could you provide the variable return values you receive. Also, did you run any additional command when the TPM connected without any errors?

0 Likes

 

Hi @snehapra ,
the return error values of the TPM_STS.x register are variables and here I put two different ones, 0x85 and 0xa8, but they change with each reboot.

When the TPM connects without errors I usually test it with the tpm2 tools by running a tpm2_pcrread or a tpm2_getrandom which work without problems. Today it connected without errors and I also tried running the createprimary command giving me this error "authorisation failure without DA implications". I tried running tpm2_clear and got this error "authorizations for objects subject to DA protection are not allowed at this time because the TPM is in DA lockout mode" but if I check with tpm2_getcap properties-variable I get

root@imx8mp-var-dart:~# tpm2_getcap properties-variable
TPM2_PT_PERSISTENT:
ownerAuthSet: 1
endorsementAuthSet: 0
lockoutAuthSet: 0
reserved1: 0
disableClear: 0
inLockout: 0
tpmGeneratedEPS: 0
reserved2: 0
TPM2_PT_STARTUP_CLEAR:
phEnable: 1
shEnable: 1
ehEnable: 1
phEnableNV: 1
reserved1: 0
orderly: 1
TPM2_PT_HR_NV_INDEX: 0x2
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x4
TPM2_PT_HR_PERSISTENT: 0x0
TPM2_PT_HR_PERSISTENT_AVAIL: 0xF
TPM2_PT_NV_COUNTERS: 0x0
TPM2_PT_NV_COUNTERS_AVAIL: 0xD
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x2
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

From what I understand, the tpm seems to be in Dictionary Attack lockout, but is not active from its properties. The command tpm2_dictionary-lockout --setup-parameters --max-tries=4294967295 --clear-lockout fails in the same way as clear- Could this be related to the random problems in the STS_x register that I sometimes get during the kernel boot phase? 

0 Likes
This widget could not be displayed.