On Thu Apr 4, 2024 at 5:19 AM EEST, William Brown wrote:
> 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
0x0901 is TPM_RC_CONTEXT_GAP, which means according to TCG spec that:
"This response code can be returned for commands that manage session
contexts. It indicates that the gap between the lowest numbered active session
and the highest numbered session is at the limits of the session tracking logic.
The remedy is to load the session context with the lowest number so that its
tracking number can be updated."
Since the code is accessing /dev/tpm0 and not /dev/tpmrm0 this issue
should be mitigated by the user space resource manager.
[1] Section 6.2 in https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-3-Commands.pdf
BR, Jarkko
