Garrett D'Amore wrote: >> >> I disagree here. The TSS API is a documented standard interface, >> there are apps that write to the TSS API >> available that someone may want to port to Solaris once we have the >> interface delivered. There is already >> an open source community developing TCG applications for TSS, so I >> think it would be bad to deliver it >> and close it off. >> > > So there *are* interesting apps in existence already. That wasn't my > understanding. > > Note that making the interface Consolidation Private, while possibly > confusing to external consumers, would primarily mean that others that > wanted to use it outside of the consolidation would need to talk to > you. I'm mostly concerned about whether or not there are > "interesting" applications that have relevance in a non-global zone. > I'm willing to concede this point, in the meantime.
Whether or not they are "interesting" is debatable :) But here are a few apps that are using the TSS: EAP-TLS using TPM identities: http://diuf.unifr.ch/people/latzec/prototyping/first Trusted GRUB - http://trousers.sourceforge.net/grub.html TPM-Tools: http://sourceforge.net/project/showfiles.php?group_id=126012&package_id=153880 >> >> The Zones issue boils down to a problem of communicating between >> zones without using a network interface. Personally, >> I don't see why one would not have the interface enabled, but I am >> sure someone can counter with many examples >> of where that is desirable. I don't think this is a problem unique >> to the TPM Support project. What has the >> ARC advised in the past? Is anyone working on a standard method for >> communicating between zones >> without the network interfaces or coming up with a way to listen on >> the localhost interface and still >> accept connections from zones? I guess door calls are one possible >> way. It would be nice if there >> were a way to open a socket that listened on "localhost + local >> zones" on the server and also be able >> to create sockets on the local zones that talk to the global-zone >> without going over the wire. > > Actually, I think what would be nice here would be some form of UNIX > domain socket or named pipes that crossed zone boundaries. The > problem with using TCP/IP is that once you have an open interface, you > have to either have sophisticated filtering rules and a firewall, or > allow for *all* IP traffic to go back and forth. I can think of many > situations where you don't want any actual network connectivity > between zones or between the global zone and local zones. > > All this is totally out of scope for this project, though. Agreed. Thanks for the comments. -Wyllys
