Edward Pilatowicz wrote:
> 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.
>
Can the TSS apps use a network to talk to the TPM and TCS daemon?
The applications here in question are mostly just PKCS#11 apps, right?
TPM is just a "better" (more secure) key store, at least for those apps.
Are there other kinds of TSS apps besides PKCS#11 clients that are
relevant for zones?
-- Garrett
> ed
>
