Persistent objects should not be flushed from context about rust-tss-esapi

[Superhepper]

I think that the specification says it pretty clear:

When an authorization session is no longer needed, TPM2_FlushContext()
may be used to delete all context associated with the session from TPM memory (see 30.6).
The session handle for this command may use an upper octet of either 0x02 or 0x03.

All Transient Objects are flushed from TPM memory on any TPM2_Startup().
A loaded Transient Object context may be flushed from TPM memory using
TPM2_FlushContext() and indicating the handle of
the loaded context to be flushed.

So flush_context can only be used if the handle is a HmacSession, LoadedSession or Transient.
But one thing that should be done for all handles when the context is dropped is to close them.
That is not so complicated to check for in tr_from_tpm_public()

To take care of the handles from evict_control what we would have to do is:

• If you make something persistent then you will have to look that handle up and say 'close but not flush'.
• If you make something persistent then the handle you provided will 'flushed' and 'closed' (isch, according to the ESAPI specification) and the handle returned should be added as 'close but not flush'.
• If you make something persistent then the handle that is returned will be closed when the context is dropped.
  -If you make something non persistent then you would have to say 'close and flush'.
• If you make something non persistent then it will be 'flushed' and 'closed' (isch, according to the ESAPI specification) and the handle will become invalid. And should be removed from the list of open handles.
• If you make something non persistent then the handle used will become invalid (i.e. closed) and the returned value will be ObjectHandle::Null. Nothing will be done with the handle when the context is dropped.

[Superhepper]

I may also have run into a bug in tpm2-tss when trying to get this to work.

tpm2-software/tpm2-tss#1930

[ionut-arm]

Hi! Thanks for reporting this, it does indeed sound like a bug. It actually made me realize it's actually a wider problem, we should try and tackle it under this issue.

For tr_from_tpm_public I think a bunch of those handle types should not be flushed: Permanent, Persistent, AttachedComponent - maybe NvIndex and Pcr but I'll defer those to @Superhepper and @puiterwijk . It might be the case that it's easier to just figure out which ones need flushing - (some of) the session handles, Transient for sure... For sessions, the Architecture spec says:

All session contexts in TPM memory are flushed on any TPM2_Startup(). The saved session contexts remain valid until a TPM Reset.

So we probably shouldn't flush SavedSession.

The reason why I mentioned a larger issue is that I noticed evict_control does not do anything to the open handles. Presumably, it should check whether the operation was succesful and depending on the operation (was it transient -> persistent or the other way around) it should change open_handles accordingly.

Maybe we need to check all methods again, make sure they all keep open_handles consistent. Maybe we also need some methods on Context to let the user decide if some handles shouldn't be flushed - it would also help mitigate any problem like this in the future.

[Superhepper]

I got it all wrong. Either you flush a handle or you close a handle. You cannot do both. FlushContext removes all the data from the TPM and cleans up all the Esys resources while close only cleans up the Esys resources and should therefor be used with handles that we are not allowed to flush.