Edward Pilatowicz writes: > On Mon, Dec 01, 2008 at 04:00:30PM -0500, James Carlson wrote: > > 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.
The question I'm asking is whether it's worth expending effort to put that one-zone-at-a-time hack in place rather than putting in a more lasting TSS-IPC-to-the-global-zone mechanism. > > 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.) At least in the on-line discussion, this seems to be the case. The driver is intentionally not set up to handle more than one open stream at a time, and that's why they have that daemon. Why bother with the daemon to coordinate requests if the driver can do it? > > 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. Agreed. I just don't think that it's an excuse to hack around the problem, either, and I think the one-zone assignment idea is a hack. > 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. I doubt it's substantially more complex than providing (say) a door or AF_UNIX socket in each zone that provides redirection to the global-zone resident daemon. > > 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. Yuck. > 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.) That sounds like the recipe for confusion. I would actually expect that the global zone's daemon would start early enough in the boot process that it would _have to_ be disabled administratively in order to make use of that one-zone-hot mechanism. Otherwise, it would take exclusive control, and the zone assigned to use the TPM would fail. (Either block on open() or fail out; not clear which.) The upgrade scenario would involve reenabling the global zone's service and ignoring those defunct parameters. > 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. If we going to specify or even mandate something from the ARC level, I'd rather that it be a clean solution rather than a kludge that needs to be removed later. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
