On Mon, Dec 01, 2008 at 04:00:30PM -0500, James Carlson wrote: > Edward Pilatowicz writes: > > 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. > > We end up being forced to support that wart going forward. >
eventually if the tpm device is virtualized (or another communication mechanism comes along that makes the zones support seamless) then we just EOL this attribute and zonecfg/zoneadm can ignore it if it's present. > Since it's clear that (for whatever reason) the device driver "can't" > be fixed to behave reasonably, I think that means you need a different > IPC in order to be able to use it from within a non-global zone. > i don't recall anyone saying that this device "can't" be virtualized. (i do recall an offline discussion where the project team said they were on a tight schedule and attempting to do this would now would compromise that schedule, but i don't recall anyone saying that this is not technically possible.) > This won't be the first "doesn't play nicely with Zones" feature in > the system. I agree that it's not good that it doesn't, but I'm much > less sure that the 'assign it to one zone' approach is useful enough > that it's both interesting and worth the effort compared to a real > solution. > well, the existence of poorly integrated features is hardly a justification for introducing new features with poor integration. i guess i thought that providing this type of 'one zone' integration would be pretty trivial (requiring only some zonecfg/zoneadm changes) compared to virtualizing the tpm device driver. > > add attr > > set type=boolean > > set name=tpm > > set value=true > > That's exactly what I mean about being forced to support a wart. > > What does the system do if multiple zones have this attribute? Just > fail to boot some of them? > yep. and give out a reasonable error message telling the admin that multiple zones can't support tpm at the same time. > Once we fix TSS so that it can be accessed normally from within a > non-global zone, what does that attribute do? It doesn't disable TPM > in the global zone anymore. > once TPM/TSS zones support is fixed, the attribute can be ignored. also, the presence of the attribute wouldn't disable tpm in the global zone, the admin has to do this themselves. (just like today when you try to boot a zone that uses dynamic pools, if poold isn't running zoneadm doesn't start it, instead it tells the admin that they need to enable it.) > > 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.) > > I can see how it can be removed in favour of a completely different > scheme that doesn't involve the daemon running inside the zone at all > ... but it's not clear how it could be improved. > i was expecting this kludge would be removed if TPM/TSS zones support becomes seamless in the future. (note that i called this a stop-gap earlier, since it really isn't a replacement for full tpm/tss zones support.) that said, we could always just forgo this kludge and wait for the full feature integration. the project team is now aware of the deficiencies in their currently proposed zones integration, so it seems like this is something we'll see them address in a future case. ed
