> On 12 Apr 2024, at 08:50, Jarkko Sakkinen <[email protected]> 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/[email protected]/
>>
>> 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
