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

[Stefan Berger <stefanb@xxxxxxxxxx>]

"Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>
wrote on 09/15/2006 12:39:39 PM:

> 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.

I suppose the vtpm mamanger unseals a symmetric key
that lets you decrypt the image of the migrated virtual machine that hosts
the vTPM. The vTPM will therfore not need to serialize its 'internal' state.
State = vm image?

  stefan


> 
> -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 thattransmits
> > > > > 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