Hi all,
I've been recently working on enabling TPM support within a number of PAM modules. I'm certainly not a TPM expert, but I have noticed some issues when testing.
We have a number of tests/examples in the rust-tss-esapi project, such as an example that shows how to hmac a value:
```
# TCTI=device:/dev/tpmrm0 cargo run --example hmac --features generate-bindings
Finished dev [unoptimized + debuginfo] target(s) in 0.07s
Running `target/debug/examples/hmac`
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [] })
hmac1 = Digest(Zeroizing([54, 176, 122, 39, 222, 112, 105, 131, 3, 158, 89, 12, 38, 14, 184, 176, 97, 38, 60, 37, 9, 49, 176, 80, 191, 161, 64, 233, 163, 47, 254, 1]))
hmac2 = Digest(Zeroizing([54, 176, 122, 39, 222, 112, 105, 131, 3, 158, 89, 12, 38, 14, 184, 176, 97, 38, 60, 37, 9, 49, 176, 80, 191, 161, 64, 233, 163, 47, 254, 1]))
```
When this test program is run repeatedly, it begins to fail with:
ERROR:tcti:src/tss2-tcti/tcti-device.c:197:tcti_device_receive() Failed to get response size fd 3, got errno 14: Bad address
ERROR:esys:src/tss2-esys/api/Esys_FlushContext.c:238:Esys_FlushContext_Finish() Received a non-TPM Error
ERROR:esys:src/tss2-esys/api/Esys_FlushContext.c:89:Esys_FlushContext() Esys Finish ErrorCode (0x000a000a)
thread 'main' panicked at tss-esapi/examples/hmac.rs:170:48:
called `Result::unwrap()` on an `Err` value: TssError(Tcti(TctiReturnCode { base_error: IoError }))
stack backtrace:
This is associated with dmesg erros such as:
[83754.340909] tpm tpm0: tpm2_save_context: failed with a TPM error 0x0901
[83754.343680] tpm tpm0: A TPM error (459) occurred flushing context
[83754.345650] tpm tpm0: tpm2_commit_space: error -14
Research indicated the following issue:
https://github.com/tpm2-software/tpm2-tools/issues/2279
Since I am currently using the kernel resource manager, this may be related. To investigate further, I reviewed the TSS Resource Manager document and noted in section 3.15 a number of properties related to sessions. Dumping these I see the following values:
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [TaggedProperty { property: HrLoaded, value: 0 }] })
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [TaggedProperty { property: HrLoadedAvail, value: 3 }] })
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [TaggedProperty { property: HrActive, value: 1 }] })
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [TaggedProperty { property: HrActiveAvail, value: 63 }] })
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [TaggedProperty { property: ActiveSessionsMax, value: 64 }] })
true: TpmProperties(TaggedTpmPropertyList { tagged_tpm_properties: [TaggedProperty { property: ContextGapMax, value: 255 }] })
So we can see that there are sufficient available sessions, but that the context gap max is 0xFF per the github issue.
Checking with tpm2_getcap I see:
TPM2TOOLS_TCTI=device:/dev/tpmrm0 tpm2_getcap properties-fixed
TPM2_PT_CONTEXT_GAP_MAX:
raw: 0xFF
TPM2TOOLS_TCTI=device:/dev/tpm0 tpm2_getcap properties-fixed
TPM2_PT_CONTEXT_GAP_MAX:
raw: 0xFFFFFFFF
My assumption would be that the same issue as the github issue notes persists today, but Im certainly not an expert on the interactions that are occuring. My first assumption was that my own programs were exhausting the resources of the TPM, but after tracking the session totals and properties, I'm not sure it's something my examples are doing wrong.
However, if you wait for a few minutes, the TPM appears to "unjam" and starts to respond again.
These tests were performed on an openSUSE Tumbleweed virtual machine with a libvirt TPM provided by swtpm.
Any ideas what could be going on?
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
