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.
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
Helps a lot with large multi-module applications.
Von: Ted Kim <ted.h.kim(a)oracle.com>
Gesendet: Mittwoch, 28. April 2021 01:00
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.
On 4/27/21 9:38 AM, Ted Kim wrote:
> 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
> 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.
> tpm2 mailing list -- tpm2(a)lists.01.org
> To unsubscribe send an email to tpm2-leave(a)lists.01.org
Ted H. Kim, PhD
tpm2 mailing list -- tpm2(a)lists.01.org
To unsubscribe send an email to tpm2-leave(a)lists.01.org
Ted H. Kim, PhD