[ replies to multiple included below. ]
On Mon, Dec 01, 2008 at 10:18:26AM -0500, Wyllys Ingersoll wrote:
>
>>> That might work. Obviously, there is no problem delivering the daemon and
>>> libraries
>>> in all zones. As long as there is only 1 instance of the TPM device in
>>> the kernel,
>>> and one reader/write of that device in userland (across all zones), I see
>>> no problem
>>> having the tpm device be located in whatever zone the admin prefers to
>>> install it.
>>>
>>>
>>
>> i think this would be a good stop-gap measure. it would simplify the
>> deployment of tss based application in one non-global zone.
>>
>> as an implementation detail, you'll probably want to enhance zoneadm to
>> detect
>> when a zone is booting with a tpm device allocated to it, and have it verify
>> that there are no other booted zones with tpm devices and that the tss daemon
>> is not running in the global zone. (this keeps things user friendly, and
>> zoneadm already does similar checks to verify that other required smf
>> services
>> are running.)
>>
>> ed
>>
>
> The tpm device itself will not allow multiple readers, so I'm not sure if
> any external
> tool modification (zoneadm, etc) is even necessary. The device will
> respond to the first
> app to open it, no other apps can open the device until it gets closed
> again.
>
leveraging this behavior will result in poor failure modes.
if the global zone is using the device, then the tss daemon in non-global
zone will fail to start, there by requiring the non-global zone
administrator (who may not have access to the global zone) to figure out
why this service is failing, and if/once they do, contact the global
zone admin and ask them to disable the service there (which also assumes
that other zones don't have the service enabled as well).
On Mon, Dec 01, 2008 at 01:31:38PM -0500, James Carlson wrote:
> Wyllys Ingersoll writes:
> > The latter is prohibited by the TPM spec if another app is holding it open.
>
> It sounds like the device is really an implementation detail, and not
> something that needs to be discussed as architecture.
>
> I don't see why assigning that internal device node (with its strange
> limitations) to non-global zones would ever be a useful thing to do.
> If the limitations can be removed, then there's a reason to do this,
> as it allows a TCS daemon per zone. Otherwise, not so much.
>
well (working on the assumption that this case won't deliver seamless
TPM support to all zones), the reason i was advocating this is that it
makes it easy to deploy TSS based applications in at least one non-global
zone. (right now, admins can't deploy to any non-global rather unless
they have a certain network config, admins can't migrate zones with TSS
unless the migrate the TPM config from the global zone as well, etc.)
i agree that the tpm device is an implementation detail. so perhaps
instead of adding a device match to zonecfg, the admin could just
create a zonecfg attribute. say:
add attr
set type=boolean
set name=tpm
set value=true
end
and then zonecfg would know how to translate this into a device match
for the tpm device. (and this implementation could change in the
future as the tpm support for zones is improved.)
ed
