TPM Support [PSARC/2008/725 FastTrack timeout 11/27/2008]

[Wyllys Ingersoll]

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