WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

RE: [Xense-devel] Run vTPM in its own VM?

To: "Fischer, Anna" <anna.fischer@xxxxxx>, <Xense-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xense-devel] Run vTPM in its own VM?
From: "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
Date: Thu, 14 Sep 2006 11:30:40 -0700
Delivery-date: Thu, 14 Sep 2006 11:30:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcbX3EoolAtZZWC7TRa8j7zH3lWkJgAP9dCwAAEFeFAAALU2wA==
Thread-topic: [Xense-devel] Run vTPM in its own VM?
No, there is only 1 vtpm_manager per platform. As you noted the vTPMs
have a VTPM_MULTI_VM switch. This switch does 2 things. 1) determines if
it reads vTPM commands from a backend or from a FIFO, and 2) if it sends
vtpm control commands to the manager via a tpm frontend or another FIFO.

So in multivm mode, it looks like the following (which will either clear
things up, or completely confuse them).

                        |----- DomU1vTPM ---| |----- DomU1 ----|
                      /--> FE ~ vtpmd ~ BE <---> FE ~ vtpm drv |
|----- Dom 0 ------|  | |-------------------| |----------------|
vtpm_managerd ~ BE <--+
                      | |----- DomU2vTPM ---| |----- DomU2 ----|
                      \--> FE ~ vtpmd ~ BE <---> FE ~ vtpm drv |
                        |-------------------| |----------------|


                      ^                      ^
                      |                      |
               save/load cmds             tpm cmds


The vtpm still has this code in it. The missing code is in the manager.
To support both models the manager had become very complex. In the multi
vm case, only control commands came in. In the single vm case, the
manager received tpm commands or control commands (open/close vtpm),
handle the control commands and forward tpm commands to a vtpm, while
accepting control commands (save/load nv) on a different channel. This
was all done through 1 command handler with a mess of #ifdefs. 

I rewrote the handler routines and threading routines to be more
generalized. Now everything is mode agnostic to the number of vms except
manager/vtpmd.c. This file defines the necessary threads, FIFO, and
handlers instances. The current file is a couple hundred lines and sets
everything up for single vm. I plan on writing another vtpmd.c which
sets the manager up for multivm mode. I will then use some sort of a
selector to determine which file to compile based on your mode or maybe
build 2 apps. This is why I call it incomplete.
                                             
-Vinnie

-----Original Message-----
From: Fischer, Anna [mailto:anna.fischer@xxxxxx] 
Sent: Thursday, September 14, 2006 10:27 AM
To: Scarlata, Vincent R; Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xense-devel] Run vTPM in its own VM?

Thanks for your reply.

But do I understand it correctly that in your design you will have a
vTPM manager running in each vTPM BE domain? And you have the vTPM then
talking again through FIFOs to the vTPM manager who talks to the BE? 

However, the code seems to be designed so that the vTPMs talk directly
to the BE. Is that what you mean with that the code for this
configuration is broken? According to the currently implemented design I
don't see how such a direct communication can work as for example
capabilities like saving and loading NVRAM won't work without having the
vTPM manager in between, right?

Anna

-----Original Message-----
From: Scarlata, Vincent R [mailto:vincent.r.scarlata@xxxxxxxxx] 
Sent: Donnerstag, 14. September 2006 17:59
To: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xense-devel] Run vTPM in its own VM?

Sorry Anna, the documentation is both slightly out of date, and slightly
ahead of its time. :-)

The vtpm manager was architected to allows each vtpm instance to run in
its own VM, but during the last restructuring of the code, support for
this configuration was broken. It's now incomplete. Due to other
commitments, I won't be able to get back to this immediately, I hope to
submit a patch to re-enable this config options within a month-ish.

The way it looked and will look again is the following. A standard
config would be a Dom0, DomU1 guest, DomU1vTPM vtpm domain, ... DomUn,
DomUnvTPM. DomU1 has a tpm FE, for which DomU1vTPM has the BE. Similarly
DomU2 has a tpm FE, for which DomU2vTPM has the BE. This allows direct
communication between the DomU and it's vTPM, as you mention below. Then
all the DomU*vTPM domains have tpm FEs, for which the domain housing the
vtpm manager is the BE. By default this is Dom0, but provided that the
tpm device can be assigned to a different domain, this can be put in any
domain. The vtpm_manager's domain has the tpm driver.

This is a little heavier weight than running everything in dom0, but it
removes the manager from being a bottle neck in tpm access, since all
DomUs can access their vTPMs simultaneously (though the manager can
still only handle 1 vtpm request at a time to save internal states).
Also isolation between vtpms is established.

Do you need this functionality, or are you just doing thought
experiments?

Hopes this answers your questions,

-Vinnie Scarlata
  Trusted Platform Lab
  Corporate Technology Group
  Intel Corporation

-----Original Message-----
From: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xense-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Fischer,
Anna
Sent: Thursday, September 14, 2006 2:01 AM
To: Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xense-devel] Run vTPM in its own VM?

The README of the current Xen unstable version says that setting
VTPM_MULTI_VM allows running each vTPM in its own VM. However, compiling
with this option doesn't work on my machine and the code doesn't seem to
be complete for this option.

Did I miss to configure something or is the current implementation in
Xen not really ready for running a vTPM in a separate VM?

Can you explain to me how a communication will look like for the planned
implementation in Xen? Will all communication continue to go through the
vTPM manager and the vTPM manager talks to a kind of FE that transmits
TPM commands to a BE running in a separate domain? Or is it possible to
set up direct connections between a user domain TPM FE and the vTPM
running in an isolated VM?

Regards,
Anna

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel