On Mon, Dec 01, 2008 at 09:37:07AM -0800, Garrett D'Amore wrote:
> Wyllys Ingersoll wrote:
>>
>>>>
>>>> What would you suggest in this case?  I'm not very familiar with the
>>>> unique
>>>> requirements of Zones and device drivers.
>>>
>>> The unique requirement here is that if you're assuming in the kernel
>>> that there's only one valid stream open on the device at a time, you'd
>>> end up with one zone user blocking another from gaining access.
>>
>> Yes, that is correct.  The TPM specification states that the TPM can
>> handle only
>> 1 at a time.  Other connections are rejected.  The TCS Daemon (userland)
>> is designed
>> to handle the sequencing and manage the access to a single TPM from
>> multiple
>> sources.    That is why I originally suggested that the TPM should only
>> reside
>> in the global zone and that local zones would access it over the network
>> and be subject to access controls as specified in the tcsd.conf.
>>
>> I still believe that is probably preferable in this situation.  A
>> non-global zone
>> should be treated as a system without a resident TPM and would have to
>> use the network to access the TCS instead of getting it's own direct
>> access
>> to the device.
>>
>> I suggested that we could deliver the TPM device and libraries in all
>> zones
>> but that the administrator would have to know that only 1 zone per-system
>> is allowed to access the TPM.  That would at least allow the administrator
>> to configure any single zone to run the TCS daemon instead of forcing it
>> to
>> be in the global zone, but it still has the restriction of only 1 TCS
>> daemon per TPM.
>>
>>>
>>> If it really must be a single user at a time, then it'd have to be
>>> set up so that you can handle multiple simultaneous users within the
>>> kernel, but with just one per zoneid_t.
>> The TCS daemon is designed to be the primary access point, applications
>> are never supposed to access the device directly.
>> -Wyllys
>>
>>
> This really sounds, to me at least, like the TPM/TCS should be a global
> zone only thing.   I see little merit in making possible to run it anywhere
> else.
>

i disagree.  i got the impression that what we're really delivering here
is TSS support for applications and that the underly TPM device is an
implementation detail (since apps use TSS libraries, which access the
TSS daemon which is the component that knows about underlying (or remote
via a network) TPM provider.)

by not supporting TPM within zones what we're actually saying is that
any application which uses TSS is not sutibale for deployment within
non-global zones.  (unless you happen to have a specific networking
config, and you do special configuration in your global zone, and you
don't use zone migration, etc...)

this seems to go against the idea that zones are application containers.

ed

Reply via email to