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

["Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx>]

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?

 

-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. 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
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel