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>, "Stefan Berger" <stefanb@xxxxxxxxxx>
Subject: RE: [Xense-devel] Run vTPM in its own VM?
From: "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
Date: Mon, 18 Sep 2006 10:29:38 -0700
Cc: Xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 18 Sep 2006 10:32:14 -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: AcbYt/yQA9m1Zc8iRrC49EXiTE7P2AAKCgSwAACiWrAAVkiHoAA+TFVQ
Thread-topic: [Xense-devel] Run vTPM in its own VM?
That is exactly what I envision. The hope is to assign the TPM to the vTPM 
domain. Then give Dom0 a VTPM. This of course relies on the de-privileging of 
Dom0 in order to be effective.

-Vinnie 

-----Original Message-----
From: Fischer, Anna [mailto:anna.fischer@xxxxxx] 
Sent: Monday, September 18, 2006 3:16 AM
To: Scarlata, Vincent R; Stefan Berger
Cc: Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xense-devel] Run vTPM in its own VM?

Does that mean that you also want to move the vTPM manager out of domain 0? In 
general that would be a good thing as you could run the vTPM manager in an 
isolated (trustworthy) lightweight VM. However, you'll also need to have the 
TPM driver in another domain than domain 0, and that has to provide safe access 
to the hardware TPM. Is that an approach you're following? 

Anna

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

A critical data point is that the vtpm is not responsible for protecting its 
own internal state. This is because on startup, you cannot trust a vtpm 
instance to properly authenticate itself to itself before opening the state. 
Instead the manager uses a key (that once we have a better measurement 
infrastructure) is bound to the PCRs of the vtpm_manager, vmm, and anything 
else in the domain where the vtpm_manager resides (more motivation to pull it 
out of dom0). The manager is then trusted to differentiate between vtpms 
(should there be different implementations) as well as protect against a 
malicious vtpm opening the state saved by legit vtpm. For these reasons the 
vtpm manager handles the encryption/decryption of the vtpm state, as well as 
migration of the vtpm states.

-Vinnie

-----Original Message-----
From: Fischer, Anna [mailto:anna.fischer@xxxxxx] 
Sent: Friday, September 15, 2006 9:13 AM
To: Stefan Berger
Cc: Scarlata, Vincent R; Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xense-devel] Run vTPM in its own VM?

I suppose Vinnie can provide some more details about the vTPM manager as he 
works on its implementation... In terms of migration you're right that you have 
to migrate both VMs, but this is not as simple as in a normal VM migration 
process. You have to make sure that the binding between the vTPM VM and the 
user VM keeps up after migration. Apart from that, the vTPM might require to 
have some things attested before being allowed to move to a specific 
destination host (i.e. to make sure that it can provide a sufficiently secure 
underlying TCB). These are (some of the) things that can be realized by using 
the hardware TPM's capabilities (through the vTPM manager).

Anna

________________________________________
From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] 
Sent: Freitag, 15. September 2006 12:09
To: Fischer, Anna
Cc: Scarlata, Vincent R; Xense-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xense-devel] Run vTPM in its own VM?


"Fischer, Anna" <anna.fischer@xxxxxx> wrote on 09/15/2006 03:06:25 AM:

> Decoupling completely from the vTPM manager would also cut the 
> connection to the hardware TPM. I.e. the vTPMs state is protected by
> the hardware TPM (using the vTPM manager). Even though a link to the
> physical TPM might not be necessary for all kind of scenarios, it 
> makes things like migrating a vTPM much more secure. The vTPM 
> manager will be the right place for managing this linking, as it 
> already uses the physical TPM for some protection.
> 

It's not clear to me what the vTPM manager does once a domain has been started 
or is running? 
What is it's involvement in migration? Particularly in this architecture I had 
the impression one was going to migrate two virtual machines between two 
pysical machines. 

  Stefan 

> Anna
> 
> ________________________________________
> From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] 
> Sent: Freitag, 15. September 2006 00:56
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
> 
> 
> "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx> wrote on 
> 09/14/2006 05:01:58 PM:
> 
> > The simple case is that all the DomUvTPM domains are the same, and 
> > therefore have the same measurement. (Note these should be single 
> > app domains where the only thing in them is a kernel, vtpm, and the 
> > supporting libraries). Then the measurement of all the code in this 
> > domain goes in a PCR in the real TPM. 
> >   
> > I don't follow your question about the 2 vTPMs in Dom0 though. Can 
> > you elaborate? 
> 
> You are right, it does not make sense to spawn 2 new virtual TPM 
> instances for your virtual TPM domains. You would measure the kernel
> and initrd of the vTPM domain into the hardware TPM and not care at 
> the level of application runtime measurements taken  *inside* a vTPM domain. 
> 
> Regarding the model below. Why do you still need the vtpm_managerd 
> in dom-0? Isn't access to persistent storage for the vTPM-hosting 
> domain sufficient so the vTPM can serialize and deserialize its 
> state when need? If you shut down the vTPM-hosting domain one could 
> use the existing shutdown mechanism ('shutdown' is launched) to 
> notify the vTPM to serialize its state to persistent storage. 
> 
>    Stefan 
> 
> 
> >   
> > -Vinnie 
> > 
> > From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] 
> > Sent: Thursday, September 14, 2006 1:19 PM
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [Xense-devel] Run vTPM in its own VM?
> 
> > 
> > The question then is where to these vTPM-hosting domains stick their
> > measurements into? I guess you will have to spawn 2 virtual TPM 
> > instances in domain-0 to give those domains vTPM access. 
> > 
> > -- Stefan 
> > 
> > "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx> wrote on 
> > 09/14/2006 03:59:27 PM:
> > 
> > > Current, I guess they are "trusted," but this is an artifact of Xen 
> > > not yet having a measurement infrastructure for measuring domains 
> > > that get launched. It is not the intention to have these domains be 
> > > implicitly trusted. 
> > >   
> > > -Vinnie 
> > > 
> > > From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] 
> > > Sent: Thursday, September 14, 2006 12:53 PM
> > > To: Scarlata, Vincent R
> > > Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx; xense-devel-
> > > bounces@xxxxxxxxxxxxxxxxxxx
> > > Subject: RE: [Xense-devel] Run vTPM in its own VM?
> > 
> > > 
> > > Are DomU1vTPM and DomU2vTPM 'trusted' or are these domains also 
> > > implementing a transitive trust model with  integrity measurements 
> > > taken inside of them? 
> > > 
> > > -- Stefan 
> > > 
> > > xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/14/2006 02:30:40 PM:
> > > 
> > > > 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. Inthe 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

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

<Prev in Thread] Current Thread [Next in Thread>