On 1/16/2017 6:18 PM, James Bottomley wrote: > > Basically this means that the advice to virtualize session handles > in the TCG RM document is wrong and we have to use physical handles. > I'll redo the implementation for this ... and now, since we'll have > nothing to use as an index, it probably does make sense to have > sessions in a separate array. I can also separate isolation from > context switching ... although I really think this is less optimal: > my TPM only allows three active context handles, so if we don't > context switch them identically to transient object (which it also > only allows three of) I'm going to run out. I actually redid my > openssl_tpm_engine patches so they use session handles for parameter > encryption and HMAC based authority, so this may end up biting me > soon ...
I think you have to context save sessions, just as you do with transient objects. Otherwise, only one process at a time can connect. FWIW: The TPM specs use the following jargon: Loaded sessions: The ~3 sessions that can be resident on the TPM. Saved sessions: Sessions that have been context saved off the TPM. These have a small bit of state on the TPM to prevent replays. Active sessions: The sum of loaded and saved, typically ~64. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
