On Thu Apr 4, 2024 at 6:06 PM EEST, Jarkko Sakkinen wrote:
> 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
It's been a long while since I implemented the resource manager but out
of top of my head I'm not sure if we even expect to encounter the issue
in kernel RM as it fills and empties everything for a command
transaction.
Emphasis that I might have forgotten something but this is what I can
remember right now.
BR, Jarkko
