>> >> i disagree. i got the impression that what we're really delivering here >> is TSS support for applications and that the underly TPM device is an >> implementation detail (since apps use TSS libraries, which access the >> TSS daemon which is the component that knows about underlying (or remote >> via a network) TPM provider.) >> >> by not supporting TPM within zones what we're actually saying is that >> any application which uses TSS is not sutibale for deployment within >> non-global zones. (unless you happen to have a specific networking >> config, and you do special configuration in your global zone, and you >> don't use zone migration, etc...) >> >> this seems to go against the idea that zones are application containers. >> > > Can the TSS apps use a network to talk to the TPM and TCS daemon?
They talk to the TCS daemon which talks to the TPM. Apps don't talk to the TPM device directly, even on the same host, they always go thru the TCS Daemon (via the TSS library). > > The applications here in question are mostly just PKCS#11 apps, > right? TPM is just a "better" (more secure) key store, at least for > those apps. Not necessarily just PKCS#11. The TSS spec is a large collection of APIs for performing TPM operations, not all of them map directly to PKCS#11. We are delivering a PKCS#11 provider so that current crypto consumers can continue to use the standard PKCS11 APIs and take advantage of *some* of the secure key storage features of the TPM, but there are lots of TSS functions that cannot be covered by PKCS#11. > > Are there other kinds of TSS apps besides PKCS#11 clients that are > relevant for zones? There are lots of potential TSS applications that would not require PKCS#11 that *could* be relevant for zones, but none are written yet. The 2 projects I mentioned earlier (ZFS Crypto and Validated Execution) could possibly be TSS consumers in a zone depending on how they are implemented and depending on how we address the zones and virtualization problem for the TPM in general. -Wyllys
