i have some concerns about the zones integration proposed by this case. in general, we recommend that applications be deployed within zones since that provides an easy way to contain application configuration. with this proposal, if an administrator deploys an application in a zone which tries to use the TSS library, then they have to modify the tcsd.conf file in the global zone. this breaks up the application configuration across multiple zones and impacts zone migration, there by eliminating the application encapsulation benefits that zones provides.
this proposal also assumes that any zones which want to use the TSS library functionality will have network access to the global zone. this is an invalid assumption. exclusive ip stack zones allow for zones with network configurations which are compleatly independent of the global zone. depending on the deployment, the global zone may not even be accessible via the network. i also don't see any discussion of security issues wrt allowing remote access to the TSS daemon. once an admin decides to enable remote host access via tcsd.conf, how is authentication and authorisation of remote clients handled? looking at the tcsd.conf file, it seems that a zone administrator might want to tune these configuration parameters locally within a zone depending on the behaviour of the TSS library consumers running within the zone. that's not possible with this proposal. to me it seems to me that each zone should have it's own copy of TSS daemon with it's own tcsd.conf configuration file. It should be the responsibility of the TPM device driver to manage requests from multiple zones, with any zone device specific configuration being managed via zonecfg. (that said, i don't have a complete understanding of the TPM/TSS device interfaces, so there may be other better ways to virtualize this subsystem to work with zones, and hence i'd be more than willing to discuss options to improve the zones integration of this feature.) ed
