[tpm2] Re: [External] : AW: Re: get TPM applications to happily co-exist

[Ted Kim <ted.h.kim at oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 5506 bytes --]

Andreas,

OK, but then the problem of preventing other applications from evicting 
persistent objects from our application doesn't seem to have a solution, 
except by locking down the owner hierarchy (e.g. my application has the 
password) - which doesn't seem very friendly. How does any other 
application create a primary object, etc. ?

Anyway, thanks for the vtpm-proxy suggestion.

Thanks,
-ted


On 4/28/21 12:55 PM, Fuchs, Andreas wrote:
> 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 <ted.h.kim(a)oracle.com>
> 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 <ted.h.kim(a)oracle.com><mailto:ted.h.kim(a)oracle.com>
> Gesendet: Mittwoch, 28. April 2021 01:00
> An: tpm2(a)lists.01.org<mailto: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<mailto:tpm2(a)lists.01.org>
> To unsubscribe send an email to tpm2-leave(a)lists.01.org<mailto: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<mailto:ted.h.kim(a)oracle.com>
> +1 310-258-7515
> _______________________________________________
> tpm2 mailing list -- tpm2(a)lists.01.org<mailto:tpm2(a)lists.01.org>
> To unsubscribe send an email to tpm2-leave(a)lists.01.org<mailto: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<mailto:ted.h.kim(a)oracle.com>
> +1 310-258-7515

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