Wyllys Ingersoll wrote:
> 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.
Me too.
>
>> #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.
>
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.
>
>>
>> #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.
Ah, I suspected as much.
> 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.
Okay, that makes sense. Surely the problem of operation of TCS/TSS/TPM
with Xen^WxVM is not unique to Solaris. It would be interesting to
learn what other design approaches the upstream community is considering
to deal with this problem.
>
>
>>
>> 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.
Okay, I'll look forward to seeing the update. :-)
>
> 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.
-- Garrett
