In some cases (e.g. after a TPM resume) a transient object handle may be flushed from TPM without trunksd Resource Manager knowing about that. In that case, the TPM may re-use that handle. The current Resource Manager logic in that case will find an old virtual handle corresponding to that TPM object handle and also re-use it. 

This leads to two callers (possibly belonging to two different daemons) using the same virtual handler, while thinking they talk to two different objects. And if an application later uses this handle to access the old object, it will actually access the new one. Quite probably it will flush that object when closing the handle when it sees that it no longer works for its purposes, and that will actually unexpectedly flush the good new object for the other caller.

Add knowledge to the resource manager when to expect a new handle, and when to expect re-using an existing virtual handle. If it expects a new handle (e.g. as a result of Load) but sees that a corresponding virtual handle already exists, create a new virtual handle, and mark the old one as invalid. Similarly, track the cases when an existing handle was expected but a new virtual handle was actually created.