Ted, same thing. The physical and virtual resources mentioned in the QUote are the transient key objects. The TBS as well as the tpm2-abrmd and tpmrm provide separation for these on a per-context basis. (P.S. Microsoft is also a TCG member and tpm2-abrmd implements a TCG spec for resource managers. So this is not really a coincidence.) I am pretty certain that the TBS does not include separation for persistent key object or let alone NV indices. I'm afraid you are misinterpreting the Quoted statement. Vor vTPMs you can look at the swtpm project of Stefan Berge with the vtpm-proxy option. This gives you additional /dev/tpm1,2,... ________________________________________ Von: Ted Kim Gesendet: Mittwoch, 28. April 2021 19:50 An: Fuchs, Andreas Cc: tpm2(a)lists.01.org Betreff: Re: [External] : AW: [tpm2] Re: get TPM applications to happily co-exist Andreas, I certainly appreciate what the ABRMD or in-kernel resource manager does. But I think the MS TPM Base Services goes a bit further. Quoting something from a MS web page: Each context is only allowed to access virtual resources created specifically on its behalf, as well as the physical resources on the TPM that corresponds to those virtual resources. So for my situation, I am thinking if application A (using its own context) created some objects, application B (with a different context) would not even see them and would not be able to evict those persistent objects of the other application. ++++ Maybe in a VM environment maybe we could have multiple virtual TPMs (not just /dev/tpm0, but also /dev/tpm1 and tpm2, etc.) ? I suppose then each application could use it's own. However, I am not sure if the ABRMD or in-kernel resource manager would handle that (maybe also the virtualization SW won't do the right thing) ? But of course in bare-metal, I am not aware any system which has more than one hardware TPM. Thanks, -ted On 4/28/21 1:15 AM, Fuchs, Andreas wrote: The tpm2-abrmd as well as the in-kernel resource manager via /dev/tpmrm0 both perform isolation of "connections", i.e. each tss context (on all apis TCTI, SYS; ESYS, FAPI) has an isolated view on the TPM. That even means if an application opens two ESYS context even they are isolated from each other. Helps a lot with large multi-module applications. ________________________________________ Von: Ted Kim Gesendet: Mittwoch, 28. April 2021 01:00 An: tpm2(a)lists.01.org Betreff: [tpm2] Re: get TPM applications to happily co-exist So it looks like Microsoft has done something to keep TPM-using applications out of each others way for Windows in "TPM Base Services". Is someone doing something similar for Linux ? Is FAPI supposed to eventually do stuff like this ? Of course, I would rather use the accepted standard tool, instead of re-inventing the wheel. Thanks, -ted On 4/27/21 9:38 AM, Ted Kim wrote: Folks, The question has come up about how to get TPM applications to happily coexist with minimal coordination. One issue in the owner hierarchy is we want each application to to be able to manage it's own objects but not affect those of the other applications. So for example, we only want application A to be able to evict persistent handles owned by that application and not those of another application B. If I understand, tpm2_evictcontrol command, the authorization is on the hierarchy and not on the object. Maybe I am thinking about this wrong, but is there a way in the authorization to look at some property of the object and tell who "owns" it and then figure out if this should be allowed or not ? Otherwise, I think, we end up building some other software which knows how to authorize this on the hierarchy and keeps track of who owns what and then issues the eviction only when the owner of an object is the requester. Am open to any suggestions. Thanks, -ted _______________________________________________ tpm2 mailing list -- tpm2(a)lists.01.org To unsubscribe send an email to tpm2-leave(a)lists.01.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Ted H. Kim, PhD ted.h.kim(a)oracle.com +1 310-258-7515 _______________________________________________ tpm2 mailing list -- tpm2(a)lists.01.org To unsubscribe send an email to tpm2-leave(a)lists.01.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Ted H. Kim, PhD ted.h.kim(a)oracle.com +1 310-258-7515