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

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 <ted.h.kim@oracle.com>
Gesendet: Mittwoch, 28. April 2021 01:00
An: tpm2@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@lists.01.org
To unsubscribe send an email to tpm2-leave@lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--
Ted H. Kim, PhD
ted.h.kim@oracle.com
+1 310-258-7515
_______________________________________________
tpm2 mailing list -- tpm2@lists.01.org
To unsubscribe send an email to tpm2-leave@lists.01.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

-- 
Ted H. Kim, PhD
ted.h.kim@oracle.com
+1 310-258-7515