TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[William Brown]

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

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[Jarkko Sakkinen]

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

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[Jarkko Sakkinen]

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

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[James Bottomley]

On Thu, 2024-04-04 at 18:09 +0300, Jarkko Sakkinen wrote:
> [...]
> Emphasis that I might have forgotten something but this is what I can
> remember right now.

What you forgot is that I did originally proposed session degapping in
the kernel resource manager but it was rather complex, so you made me
take it out for lack of a use case.  It dates back to when we used the
old sourceforge tpmdd list which seems to have caused message loss, so
I'm not sure how complete this thread is:

https://lore.kernel.org/lkml/1484772489.2396.2.camel@HansenPartnership.com/

If I compare it to the fragment on sourceforge, you can see a bit more
of it (but sourceforge has lost the patch):

https://sourceforge.net/p/tpmdd/mailman/tpmdd-devel/thread/201702090906.v1996c6a015552%40wind.enjellic.com/#msg35656470

The reality is that unless you context save a session, you don't need
degapping and pretty much every TSS based use of sessions doesn't need
to save them, so people who construct TPM based systems rarely run into
this.  The exception is the tpm2-tools CLI project, which encourages
the context saving of sessions and thus can cause this.  We kept
tripping across this in the Keylime, but the eventual solution was to
dump the tpm2-tools dependency and do a direct TSS connection in the
Keylime agent.

James

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[William Brown]

> On 5 Apr 2024, at 01:49, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> The reality is that unless you context save a session, you don't need
> degapping and pretty much every TSS based use of sessions doesn't need
> to save them, so people who construct TPM based systems rarely run into
> this. 

This is the odd part - I'm *not* context saving sessions here.

     Running `target/debug/examples/hmac`
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 }] })

     Running `target/debug/examples/hmac`
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 }] })

     Running `target/debug/examples/hmac`
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 }] })


I could be completely wrong, but my reading of the specification is that HrActive/HrLoaded are the values of interest here, and we can see they remain at 0/1 for each test as the sessions and loaded objects are removed at the end of each test. 

And yet, I'm running into the error 0x0901. So something else is going on that I'm not 100% sure about.


--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[William Brown]

> On 5 Apr 2024, at 01:06, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> Since the code is accessing /dev/tpm0 and not /dev/tpmrm0 this issue
> should be mitigated by the user space resource manager.

My code is operating via /dev/tpmrm0, not /dev/tpm0. And after each iteration, all sessions are cleared and removed. 

If I operate on /dev/tpm0 the issue goes away. So the error is actually in the resource manager itself. 

--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[Jarkko Sakkinen]

On Thu Apr 4, 2024 at 6:49 PM EEST, James Bottomley wrote:
> On Thu, 2024-04-04 at 18:09 +0300, Jarkko Sakkinen wrote:
> > [...]
> > Emphasis that I might have forgotten something but this is what I can
> > remember right now.
>
> What you forgot is that I did originally proposed session degapping in
> the kernel resource manager but it was rather complex, so you made me
> take it out for lack of a use case.  It dates back to when we used the
> old sourceforge tpmdd list which seems to have caused message loss, so
> I'm not sure how complete this thread is:

I might be forgetting some detail to contxt gap but since kernel flushes
every single object per transaction contextCounter should be updated all
the time and thus there should not be too large gap that would cause
emitting this error.

I quickly reviewed section 30.5 for architecture specificaton to check
if I got it right and it says that: "On receiving this error, the
management software either would explicitly flush old session contexts
or would load the old session contexts to update their associated
counter values.."

You could cause the error even with kernel RM if e,g. a process with
access to /dev/tpm0 purposely populates the chip with objects that it
does not flush so it is then inevitable over time...

I still think that kernel RM should not do any pro-active handling to
this albeit I have to admit I did not remember what I said about the
topic back then :-)

>
> https://lore.kernel.org/lkml/1484772489.2396.2.camel@HansenPartnership.com/
>
> If I compare it to the fragment on sourceforge, you can see a bit more
> of it (but sourceforge has lost the patch):
>
> https://sourceforge.net/p/tpmdd/mailman/tpmdd-devel/thread/201702090906.v1996c6a015552%40wind.enjellic.com/#msg35656470
>
> The reality is that unless you context save a session, you don't need
> degapping and pretty much every TSS based use of sessions doesn't need
> to save them, so people who construct TPM based systems rarely run into
> this.  The exception is the tpm2-tools CLI project, which encourages
> the context saving of sessions and thus can cause this.  We kept
> tripping across this in the Keylime, but the eventual solution was to
> dump the tpm2-tools dependency and do a direct TSS connection in the
> Keylime agent.

If someone is interested to deal with this error in tpm2-tools (or what
ever that stacks name is), e.g. Android TPM stack does address the
error.

I agree with you tho that properly implemented application wisely you
should never encounter the error...

> James

BR, Jarkko

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[William Brown]

> On 12 Apr 2024, at 08:50, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> 
> On Thu Apr 4, 2024 at 6:49 PM EEST, James Bottomley wrote:
>> On Thu, 2024-04-04 at 18:09 +0300, Jarkko Sakkinen wrote:
>>> [...]
>>> Emphasis that I might have forgotten something but this is what I can
>>> remember right now.
>> 
>> What you forgot is that I did originally proposed session degapping in
>> the kernel resource manager but it was rather complex, so you made me
>> take it out for lack of a use case.  It dates back to when we used the
>> old sourceforge tpmdd list which seems to have caused message loss, so
>> I'm not sure how complete this thread is:
> 
> I might be forgetting some detail to contxt gap but since kernel flushes
> every single object per transaction contextCounter should be updated all
> the time and thus there should not be too large gap that would cause
> emitting this error.
> 
> I quickly reviewed section 30.5 for architecture specificaton to check
> if I got it right and it says that: "On receiving this error, the
> management software either would explicitly flush old session contexts
> or would load the old session contexts to update their associated
> counter values.."

The issue is that we *are* flushing session contexts and this error is still occurring.

> 
> You could cause the error even with kernel RM if e,g. a process with
> access to /dev/tpm0 purposely populates the chip with objects that it
> does not flush so it is then inevitable over time...
> 
> I still think that kernel RM should not do any pro-active handling to
> this albeit I have to admit I did not remember what I said about the
> topic back then :-)
> 
>> 
>> https://lore.kernel.org/lkml/1484772489.2396.2.camel@HansenPartnership.com/
>> 
>> If I compare it to the fragment on sourceforge, you can see a bit more
>> of it (but sourceforge has lost the patch):
>> 
>> https://sourceforge.net/p/tpmdd/mailman/tpmdd-devel/thread/201702090906.v1996c6a015552%40wind.enjellic.com/#msg35656470
>> 
>> The reality is that unless you context save a session, you don't need
>> degapping and pretty much every TSS based use of sessions doesn't need
>> to save them, so people who construct TPM based systems rarely run into
>> this.  The exception is the tpm2-tools CLI project, which encourages
>> the context saving of sessions and thus can cause this.  We kept
>> tripping across this in the Keylime, but the eventual solution was to
>> dump the tpm2-tools dependency and do a direct TSS connection in the
>> Keylime agent.
> 
> If someone is interested to deal with this error in tpm2-tools (or what
> ever that stacks name is), e.g. Android TPM stack does address the
> error.
> 
> I agree with you tho that properly implemented application wisely you
> should never encounter the error...
> 
>> James
> 
> BR, Jarkko

-- 
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[Jarkko Sakkinen]

On Fri Apr 5, 2024 at 3:24 AM EEST, William Brown wrote:
>
>
> > On 5 Apr 2024, at 01:49, James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > The reality is that unless you context save a session, you don't need
> > degapping and pretty much every TSS based use of sessions doesn't need
> > to save them, so people who construct TPM based systems rarely run into
> > this. 
>
> This is the odd part - I'm *not* context saving sessions here.
>
>      Running `target/debug/examples/hmac`
> 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 }] })
>
>      Running `target/debug/examples/hmac`
> 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 }] })
>
>      Running `target/debug/examples/hmac`
> 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 }] })
>
>
> I could be completely wrong, but my reading of the specification is that HrActive/HrLoaded are the values of interest here, and we can see they remain at 0/1 for each test as the sessions and loaded objects are removed at the end of each test. 
>
> And yet, I'm running into the error 0x0901. So something else is going on that I'm not 100% sure about.

We should catch all TPM2_StartAuthSession commands written to /dev/tpm0.

In practice this means checking the 32-bit value in buf[6] of the second
parameter of tpm_transmit().

This could be e.g. checked with bpftrace by hooking kprobe into the
function and comparing that to 0x00000176. It is in big-endian order.

I can try to bake a script for this if you need help...

That way we can catch all session creations.

>
>
> --
> Sincerely,
>
> William Brown
>
> Senior Software Engineer,
> Identity and Access Management
> SUSE Labs, Australia


BR, Jarkko

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[Jarkko Sakkinen]

On Fri Apr 5, 2024 at 3:24 AM EEST, William Brown wrote:
>
>
> > On 5 Apr 2024, at 01:06, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > 
> > Since the code is accessing /dev/tpm0 and not /dev/tpmrm0 this issue
> > should be mitigated by the user space resource manager.
>
> My code is operating via /dev/tpmrm0, not /dev/tpm0. And after each iteration, all sessions are cleared and removed. 
>
> If I operate on /dev/tpm0 the issue goes away. So the error is actually in the resource manager itself. 

Ah, my previous response about kprobe hook is still relevant.

Kernel RM can cause context gap error if user space leaves a 
stall session long enough. Before making any decisions we should
be aware first what are the exact conditions in this case.

Sorry for late response. I was sick for most of last wee.

BR, Jarkko

Re: TPM error 0x0901, possibly related to TPM2_PT_CONTEXT_GAP_MAX

[Jarkko Sakkinen]

On Fri Apr 12, 2024 at 2:21 AM EEST, William Brown wrote:
>
>
> > On 12 Apr 2024, at 08:50, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > 
> > On Thu Apr 4, 2024 at 6:49 PM EEST, James Bottomley wrote:
> >> On Thu, 2024-04-04 at 18:09 +0300, Jarkko Sakkinen wrote:
> >>> [...]
> >>> Emphasis that I might have forgotten something but this is what I can
> >>> remember right now.
> >> 
> >> What you forgot is that I did originally proposed session degapping in
> >> the kernel resource manager but it was rather complex, so you made me
> >> take it out for lack of a use case.  It dates back to when we used the
> >> old sourceforge tpmdd list which seems to have caused message loss, so
> >> I'm not sure how complete this thread is:
> > 
> > I might be forgetting some detail to contxt gap but since kernel flushes
> > every single object per transaction contextCounter should be updated all
> > the time and thus there should not be too large gap that would cause
> > emitting this error.
> > 
> > I quickly reviewed section 30.5 for architecture specificaton to check
> > if I got it right and it says that: "On receiving this error, the
> > management software either would explicitly flush old session contexts
> > or would load the old session contexts to update their associated
> > counter values.."
>
> The issue is that we *are* flushing session contexts and this error is still occurring.

Was there a way that I could reproduce the same workload or something
simpler that would reproduce the issue on my side?

BR, Jarkko