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

[Stefan Berger <stefanb@xxxxxxxxxx>]

"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