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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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