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. 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. 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. > 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? 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. > 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 favor 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. -- 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
