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.

Someday, might we not want the TPM stack to do more than just PKCS#11 
and generic crypto?  (I.e. TPM was also designed to support trusted 
verification of the platform itself -- the kernel bit.)  I think if we 
want to allow for future developments in that area, it might be better 
to constrain the daemon to the global zone only for now.  (This 
shouldn't be too much of a limitation for local zones, since for various 
reasons the global zone has to be trusted with at least the same level 
of privilege as the local zone.  The local zones just need to be 
configured to use a network interface to access the TCS on the global zone.)

    -- Garrett


Reply via email to