Garrett D'Amore wrote: > A few thoughts here: > > #1: This is a fast track. If we are going to start insisting that the > project team make significant changes to the project (especially > changes to which the project team doesn't readily agree), then the > project should probably be derailed.
I hope it doesn't come to that. I'd like to converge and get consensus today so this case can be closed/approved in the meeting tomorrow. > #2: The only interesting consumers *right now* are PKCS#11. I think > enabling PKCS#11 in the global zone is useful enough, that it ought to > be allowed to proceed even if the final solution isn't quite what we > want. This is especially true since PKCS#11 by its very nature > shields applications from changes to underlying plumbing that might be > necessary later. > > #3: I propose that in the meantime, the TSS API be reduced to > Consolidation Private binding, if not already at that level. Since > there are no consumers yet, this seems fairly reasonable and unlikely > to cause undue harm to projects. 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. > > #4: If the only reason that the daemon exists is to serialize access > to the TPM device (and I confess I'm not entirely convinced that this > assertion is true), then at some point in the future, It Would Be Nice > if the daemon could be eliminated, replaced with a fully zone-aware > and concurrent version of the TPM driver. I'm not sure what the > challenges to solve in that are, but hopefully the project team can > elucidate them when the time comes. The TCS daemon provides many services that do not belong in the kernel (TPM driver). It manages a registry of "persistent keys" that apps may use in addition to swapping of contexts when multiple applications are accessing it at the same time. The behavior and design of the TCS is also documented in the TSS specifications. Additionally, the TCS Daemon is a critical part of the TrouSerS package which is what we are delivering and to remove it would be to effectively fork from the upstream community that we are trying to follow, thus creating a significant amount of work for us. > > So, in the mean time, I think we need to either move ahead with a > global zone only solution (for now) and hope the project team will > follow up with a future case that addresses the virtualization > problem, or we need to take the first option and derail. Agreed, we would like to move ahead with the global-zone-only solution for now. The workaround for any Zone based app that wants to use the TSS will be to enable and interface and talk to the global zone over that network interface like any other network-based host. It's not ideal, but it is a workable solution for now, IMO. I would like to find a clean, long-term solution to the Zones and Virtualization problems. There is a TCG Working Group that is developing standards for Virtualizing TPMs and we will follow up with that group and hopefully be able to implement their final spec at some point. 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. -Wyllys
