> On 12 Apr 2024, at 08:50, Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx/ >> >> 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
