Run vTPM in its own VM?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Run vTPM in its own VM?

Fischer, Anna
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
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

Re: Run vTPM in its own VM?

Stefan Berger

[hidden email] wrote on 09/14/2006 05:00:56 AM:

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


I am not familiar with the option above since I am running a different implementation of a VTPM, but I can say that it should generally be possible to run a vTPM in a separate domain, but I haven't done this in a long time. There exists an option when defining the vtpm in the VM configuration file to have it's backend located in a different domain than domain-0. Typically such an entry looks like

vtpm=['backend=0,instance=1']

to talk to a vTPM in domain-0 ( => backend=0 ).

There's one catch, though, and that's that all the hotplug scripts that are typically doing the life-cycle management of the vTPM instances now also have to be installed in that domain along with hotplug daemon etc.. I myself haven't run the vTPM in any other domain than domain-0 in a long time.

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


It is possible to connect them directly with the vm configuration option above.
It should be possible to start a 2nd domain whose only purpose would be to run the vTPM - along with the hotplug stuff mentioned above running in that domain. That domain would have to be started from domain-0. However, you have a gap then if it's about taking integrity measurements of applications and a correct 'trust' chain. The proper way of doing this would be to have that vTPM-hosting domain started before domain 0 (including all the complications on how to access persistent storage etc.).
Can you tell us a bit more about what you are planning on doing?

  Stefan

>
> Regards,
> Anna
>
> _______________________________________________
> Xense-devel mailing list
> [hidden email]
> http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Fischer,
Anna
Sent: Thursday, September 14, 2006 2:01 AM
To: [hidden email]
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
[hidden email]
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Fischer, Anna
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:[hidden email]]
Sent: Donnerstag, 14. September 2006 17:59
To: Fischer, Anna; [hidden email]
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Fischer,
Anna
Sent: Thursday, September 14, 2006 2:01 AM
To: [hidden email]
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
[hidden email]
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
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:[hidden email]]
Sent: Thursday, September 14, 2006 10:27 AM
To: Scarlata, Vincent R; [hidden email]
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:[hidden email]]
Sent: Donnerstag, 14. September 2006 17:59
To: Fischer, Anna; [hidden email]
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Fischer,
Anna
Sent: Thursday, September 14, 2006 2:01 AM
To: [hidden email]
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
[hidden email]
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Stefan Berger

Are DomU1vTPM and DomU2vTPM 'trusted' or are these domains also implementing a transitive trust model with  integrity measurements taken inside of them?

-- Stefan

[hidden email] 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:[hidden email]]
> Sent: Thursday, September 14, 2006 10:27 AM
> To: Scarlata, Vincent R; [hidden email]
> 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:[hidden email]]
> Sent: Donnerstag, 14. September 2006 17:59
> To: Fischer, Anna; [hidden email]
> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Fischer,
> Anna
> Sent: Thursday, September 14, 2006 2:01 AM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.xensource.com/xense-devel
>
> _______________________________________________
> Xense-devel mailing list
> [hidden email]
> http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
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:[hidden email]]
Sent: Thursday, September 14, 2006 12:53 PM
To: Scarlata, Vincent R
Cc: Fischer, Anna; [hidden email]; [hidden email]
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

[hidden email] 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:[hidden email]]
> Sent: Thursday, September 14, 2006 10:27 AM
> To: Scarlata, Vincent R; [hidden email]
> 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:[hidden email]]
> Sent: Donnerstag, 14. September 2006 17:59
> To: Fischer, Anna; [hidden email]
> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Fischer,
> Anna
> Sent: Thursday, September 14, 2006 2:01 AM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.xensource.com/xense-devel
>
> _______________________________________________
> Xense-devel mailing list
> [hidden email]
> http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Stefan Berger

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" <[hidden email]> 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:[hidden email]]
> Sent: Thursday, September 14, 2006 12:53 PM
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]; xense-devel-
> [hidden email]
> 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
>
> [hidden email] 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 10:27 AM
> > To: Scarlata, Vincent R; [hidden email]
> > 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:[hidden email]]
> > Sent: Donnerstag, 14. September 2006 17:59
> > To: Fischer, Anna; [hidden email]
> > 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: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Fischer,
> > Anna
> > Sent: Thursday, September 14, 2006 2:01 AM
> > To: [hidden email]
> > 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
> > [hidden email]
> > http://lists.xensource.com/xense-devel
> >
> > _______________________________________________
> > Xense-devel mailing list
> > [hidden email]
> > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
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:[hidden email]]
Sent: Thursday, September 14, 2006 1:19 PM
To: Scarlata, Vincent R
Cc: Fischer, Anna; [hidden email]
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" <[hidden email]> 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:[hidden email]]
> Sent: Thursday, September 14, 2006 12:53 PM
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]; xense-devel-
> [hidden email]
> 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
>
> [hidden email] 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 10:27 AM
> > To: Scarlata, Vincent R; [hidden email]
> > 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:[hidden email]]
> > Sent: Donnerstag, 14. September 2006 17:59
> > To: Fischer, Anna; [hidden email]
> > 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: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Fischer,
> > Anna
> > Sent: Thursday, September 14, 2006 2:01 AM
> > To: [hidden email]
> > 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
> > [hidden email]
> > http://lists.xensource.com/xense-devel
> >
> > _______________________________________________
> > Xense-devel mailing list
> > [hidden email]
> > http://lists.xensource.com/xense-devel
_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Stefan Berger

"Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> Sent: Thursday, September 14, 2006 1:19 PM
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]
> 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" <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 12:53 PM
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; [hidden email]; xense-devel-
> > [hidden email]
> > 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
> >
> > [hidden email] 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:[hidden email]]
> > > Sent: Thursday, September 14, 2006 10:27 AM
> > > To: Scarlata, Vincent R; [hidden email]
> > > 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:[hidden email]]
> > > Sent: Donnerstag, 14. September 2006 17:59
> > > To: Fischer, Anna; [hidden email]
> > > 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: [hidden email]
> > > [mailto:[hidden email]] On Behalf Of Fischer,
> > > Anna
> > > Sent: Thursday, September 14, 2006 2:01 AM
> > > To: [hidden email]
> > > 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
> > > [hidden email]
> > > http://lists.xensource.com/xense-devel
> > >
> > > _______________________________________________
> > > Xense-devel mailing list
> > > [hidden email]
> > > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Fischer, Anna
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.

Anna

________________________________________
From: Stefan Berger [mailto:[hidden email]]
Sent: Freitag, 15. September 2006 00:56
To: Scarlata, Vincent R
Cc: Fischer, Anna; [hidden email]
Subject: RE: [Xense-devel] Run vTPM in its own VM?


"Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> Sent: Thursday, September 14, 2006 1:19 PM
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]
> 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" <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 12:53 PM
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; [hidden email]; xense-devel-
> > [hidden email]
> > 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
> >
> > [hidden email] 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:[hidden email]]
> > > Sent: Thursday, September 14, 2006 10:27 AM
> > > To: Scarlata, Vincent R; [hidden email]
> > > 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:[hidden email]]
> > > Sent: Donnerstag, 14. September 2006 17:59
> > > To: Fischer, Anna; [hidden email]
> > > 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: [hidden email]
> > > [mailto:[hidden email]] On Behalf Of Fischer,
> > > Anna
> > > Sent: Thursday, September 14, 2006 2:01 AM
> > > To: [hidden email]
> > > 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
> > > [hidden email]
> > > http://lists.xensource.com/xense-devel
> > >
> > > _______________________________________________
> > > Xense-devel mailing list
> > > [hidden email]
> > > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Fischer, Anna
In reply to this post by Stefan Berger
Stefan,

Thanks for your answer.
However, I think the multivm mode approach that Vinnie described in his last post is a much more secure design than running all vTPMs in domain 0.
As I don't know details about your internal vTPM implementation, I can only refer to the public Xen implementation which runs the vTPMs as user processes in domain 0. This doesn't seem to be the most secure approach to me as it doesn't provide very good isolation for vTPMs. Furthermore the vTPM manager becomes a real bottleneck if you have many VMs running on one platform. Apart from that domain 0 already holds a lot of complexity of Xen and therefore it is a good thing to move components out as much as possible. Running vTPMs in their own VM will also protect domain 0 from malfunctioning TPM drivers.

Anna

________________________________________
From: Stefan Berger [mailto:[hidden email]]
Sent: Donnerstag, 14. September 2006 17:36
To: Fischer, Anna
Cc: [hidden email]
Subject: Re: [Xense-devel] Run vTPM in its own VM?


[hidden email] wrote on 09/14/2006 05:00:56 AM:

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

I am not familiar with the option above since I am running a different implementation of a VTPM, but I can say that it should generally be possible to run a vTPM in a separate domain, but I haven't done this in a long time. There exists an option when defining the vtpm in the VM configuration file to have it's backend located in a different domain than domain-0. Typically such an entry looks like

vtpm=['backend=0,instance=1']

to talk to a vTPM in domain-0 ( => backend=0 ).

There's one catch, though, and that's that all the hotplug scripts that are typically doing the life-cycle management of the vTPM instances now also have to be installed in that domain along with hotplug daemon etc.. I myself haven't run the vTPM in any other domain than domain-0 in a long time.

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

It is possible to connect them directly with the vm configuration option above.
It should be possible to start a 2nd domain whose only purpose would be to run the vTPM - along with the hotplug stuff mentioned above running in that domain. That domain would have to be started from domain-0. However, you have a gap then if it's about taking integrity measurements of applications and a correct 'trust' chain. The proper way of doing this would be to have that vTPM-hosting domain started before domain 0 (including all the complications on how to access persistent storage etc.).
Can you tell us a bit more about what you are planning on doing?

  Stefan

>
> Regards,
> Anna
>
> _______________________________________________
> Xense-devel mailing list
> [hidden email]
> http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Fischer, Anna
In reply to this post by Scarlata, Vincent R
Thanks very much, this looks much more reasonable to me now. But what if
I wanted to have a vTPM that is not completely implemented in software,
but more a kind of pass-through device to the hardware TPM (i.e. to
protect private keys and never reveal them in memory). I've seen that
the vTPM manager can handle TPM commands that come in as vTPM commands
and forward them to the hardware TPM. Is this already usable and is the
current vTPM itself already capable of just forwarding commands instead
of processing them?

Anna

-----Original Message-----
From: Scarlata, Vincent R [mailto:[hidden email]]
Sent: Donnerstag, 14. September 2006 19:31
To: Fischer, Anna; [hidden email]
Subject: RE: [Xense-devel] Run vTPM in its own VM?

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:[hidden email]]
Sent: Thursday, September 14, 2006 10:27 AM
To: Scarlata, Vincent R; [hidden email]
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:[hidden email]]
Sent: Donnerstag, 14. September 2006 17:59
To: Fischer, Anna; [hidden email]
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Fischer,
Anna
Sent: Thursday, September 14, 2006 2:01 AM
To: [hidden email]
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
[hidden email]
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Stefan Berger
In reply to this post by Fischer, Anna

"Fischer, Anna" <[hidden email]> 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:[hidden email]]
> Sent: Freitag, 15. September 2006 00:56
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
>
> "Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 1:19 PM
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; [hidden email]
> > 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" <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, September 14, 2006 12:53 PM
> > > To: Scarlata, Vincent R
> > > Cc: Fischer, Anna; [hidden email]; xense-devel-
> > > [hidden email]
> > > 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
> > >
> > > [hidden email] 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:[hidden email]]
> > > > Sent: Thursday, September 14, 2006 10:27 AM
> > > > To: Scarlata, Vincent R; [hidden email]
> > > > 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:[hidden email]]
> > > > Sent: Donnerstag, 14. September 2006 17:59
> > > > To: Fischer, Anna; [hidden email]
> > > > 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: [hidden email]
> > > > [mailto:[hidden email]] On Behalf Of Fischer,
> > > > Anna
> > > > Sent: Thursday, September 14, 2006 2:01 AM
> > > > To: [hidden email]
> > > > 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
> > > > [hidden email]
> > > > http://lists.xensource.com/xense-devel
> > > >
> > > > _______________________________________________
> > > > Xense-devel mailing list
> > > > [hidden email]
> > > > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Fischer, Anna
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:[hidden email]]
Sent: Freitag, 15. September 2006 12:09
To: Fischer, Anna
Cc: Scarlata, Vincent R; [hidden email]
Subject: RE: [Xense-devel] Run vTPM in its own VM?


"Fischer, Anna" <[hidden email]> 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:[hidden email]]
> Sent: Freitag, 15. September 2006 00:56
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
>
> "Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 1:19 PM
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; [hidden email]
> > 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" <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, September 14, 2006 12:53 PM
> > > To: Scarlata, Vincent R
> > > Cc: Fischer, Anna; [hidden email]; xense-devel-
> > > [hidden email]
> > > 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
> > >
> > > [hidden email] 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:[hidden email]]
> > > > Sent: Thursday, September 14, 2006 10:27 AM
> > > > To: Scarlata, Vincent R; [hidden email]
> > > > 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:[hidden email]]
> > > > Sent: Donnerstag, 14. September 2006 17:59
> > > > To: Fischer, Anna; [hidden email]
> > > > 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: [hidden email]
> > > > [mailto:[hidden email]] On Behalf Of Fischer,
> > > > Anna
> > > > Sent: Thursday, September 14, 2006 2:01 AM
> > > > To: [hidden email]
> > > > 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
> > > > [hidden email]
> > > > http://lists.xensource.com/xense-devel
> > > >
> > > > _______________________________________________
> > > > Xense-devel mailing list
> > > > [hidden email]
> > > > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
This is already supported, even in the single VM model. At any time, a
vtpm can issue a request to the manager (similar to the way you request
save/load state) to access the TPM below. On one of my configurations
(not submitted but available upon request) that have the vtpm's copy
certain hwpcrs during its initialization steps. Note, however, on
commands that use authorization digests, it won't be as simple has
forwarding the commands down from vtpm to manager to tpm, you'll need to
be more careful to ensure the auth sessions are maintained as the client
expects.

-Vinnie  

-----Original Message-----
From: Fischer, Anna [mailto:[hidden email]]
Sent: Friday, September 15, 2006 12:54 AM
To: Scarlata, Vincent R; [hidden email]
Subject: RE: [Xense-devel] Run vTPM in its own VM?

Thanks very much, this looks much more reasonable to me now. But what if
I wanted to have a vTPM that is not completely implemented in software,
but more a kind of pass-through device to the hardware TPM (i.e. to
protect private keys and never reveal them in memory). I've seen that
the vTPM manager can handle TPM commands that come in as vTPM commands
and forward them to the hardware TPM. Is this already usable and is the
current vTPM itself already capable of just forwarding commands instead
of processing them?

Anna

-----Original Message-----
From: Scarlata, Vincent R [mailto:[hidden email]]
Sent: Donnerstag, 14. September 2006 19:31
To: Fischer, Anna; [hidden email]
Subject: RE: [Xense-devel] Run vTPM in its own VM?

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:[hidden email]]
Sent: Thursday, September 14, 2006 10:27 AM
To: Scarlata, Vincent R; [hidden email]
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:[hidden email]]
Sent: Donnerstag, 14. September 2006 17:59
To: Fischer, Anna; [hidden email]
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: [hidden email]
[mailto:[hidden email]] On Behalf Of Fischer,
Anna
Sent: Thursday, September 14, 2006 2:01 AM
To: [hidden email]
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
[hidden email]
http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Stefan Berger

[hidden email] wrote on 09/15/2006 12:18:12 PM:

> This is already supported, even in the single VM model. At any time, a
> vtpm can issue a request to the manager (similar to the way you request
> save/load state) to access the TPM below. On one of my configurations
> (not submitted but available upon request) that have the vtpm's copy
> certain hwpcrs during its initialization steps. Note, however, on


You will also have to clone the logs related to those PCRs and carry them with you when you migrate.
Now if you copy the PCRs upon creation, what do you do with the PCR register values after migration? Do they still reflect the old environment?

> commands that use authorization digests, it won't be as simple has
> forwarding the commands down from vtpm to manager to tpm, you'll need to
> be more careful to ensure the auth sessions are maintained as the client
> expects.


Which commands are you for example forwarding to the hardware TPM? Are you rooting your key tree to the SRK of the hardware TPM?

  Stefan

>
> -Vinnie  
>
> -----Original Message-----
> From: Fischer, Anna [mailto:[hidden email]]
> Sent: Friday, September 15, 2006 12:54 AM
> To: Scarlata, Vincent R; [hidden email]
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
> Thanks very much, this looks much more reasonable to me now. But what if
> I wanted to have a vTPM that is not completely implemented in software,
> but more a kind of pass-through device to the hardware TPM (i.e. to
> protect private keys and never reveal them in memory). I've seen that
> the vTPM manager can handle TPM commands that come in as vTPM commands
> and forward them to the hardware TPM. Is this already usable and is the
> current vTPM itself already capable of just forwarding commands instead
> of processing them?
>
> Anna
>
> -----Original Message-----
> From: Scarlata, Vincent R [mailto:[hidden email]]
> Sent: Donnerstag, 14. September 2006 19:31
> To: Fischer, Anna; [hidden email]
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
> 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:[hidden email]]
> Sent: Thursday, September 14, 2006 10:27 AM
> To: Scarlata, Vincent R; [hidden email]
> 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:[hidden email]]
> Sent: Donnerstag, 14. September 2006 17:59
> To: Fischer, Anna; [hidden email]
> 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: [hidden email]
> [mailto:[hidden email]] On Behalf Of Fischer,
> Anna
> Sent: Thursday, September 14, 2006 2:01 AM
> To: [hidden email]
> 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
> [hidden email]
> http://lists.xensource.com/xense-devel
>
> _______________________________________________
> Xense-devel mailing list
> [hidden email]
> http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
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:[hidden email]]
Sent: Friday, September 15, 2006 9:13 AM
To: Stefan Berger
Cc: Scarlata, Vincent R; [hidden email]
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:[hidden email]]
Sent: Freitag, 15. September 2006 12:09
To: Fischer, Anna
Cc: Scarlata, Vincent R; [hidden email]
Subject: RE: [Xense-devel] Run vTPM in its own VM?


"Fischer, Anna" <[hidden email]> 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:[hidden email]]
> Sent: Freitag, 15. September 2006 00:56
> To: Scarlata, Vincent R
> Cc: Fischer, Anna; [hidden email]
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
>
> "Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, September 14, 2006 1:19 PM
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; [hidden email]
> > 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" <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, September 14, 2006 12:53 PM
> > > To: Scarlata, Vincent R
> > > Cc: Fischer, Anna; [hidden email]; xense-devel-
> > > [hidden email]
> > > 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
> > >
> > > [hidden email] 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:[hidden email]]
> > > > Sent: Thursday, September 14, 2006 10:27 AM
> > > > To: Scarlata, Vincent R; [hidden email]
> > > > 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:[hidden email]]
> > > > Sent: Donnerstag, 14. September 2006 17:59
> > > > To: Fischer, Anna; [hidden email]
> > > > 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: [hidden email]
> > > > [mailto:[hidden email]] On Behalf Of Fischer,
> > > > Anna
> > > > Sent: Thursday, September 14, 2006 2:01 AM
> > > > To: [hidden email]
> > > > 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
> > > > [hidden email]
> > > > http://lists.xensource.com/xense-devel
> > > >
> > > > _______________________________________________
> > > > Xense-devel mailing list
> > > > [hidden email]
> > > > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Scarlata, Vincent R
In reply to this post by Fischer, Anna
 

>________________________________
>
>From: Stefan Berger [mailto:[hidden email]]
>Sent: Friday, September 15, 2006 9:34 AM
>To: Scarlata, Vincent R
>Cc: Fischer, Anna; [hidden email];
[hidden email]
>Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
>
>
> [hidden email] wrote on 09/15/2006 12:18:12
PM:
>
> > This is already supported, even in the single VM model. At any time,
a
>> vtpm can issue a request to the manager (similar to the way you
request
>> save/load state) to access the TPM below. On one of my configurations
>> (not submitted but available upon request) that have the vtpm's copy
>> certain hwpcrs during its initialization steps. Note, however, on

>You will also have to clone the logs related to those PCRs and carry
them with you when you migrate.
>Now if you copy the PCRs upon creation, what do you do with the PCR
register values after migration? Do they still
>reflect the old environment?

The code I mentioned is being used for a very specific environment where
not all of the functions in xen are used. I meant it more as an
illustrative statement that not only is calling the tpm from a vtpm
supported, there exist code that is using it. The code hasn't been
checked in to the tree, because as you point out, it is not necessarily
a general purpose approach to vPCR usage.

>> commands that use authorization digests, it won't be as simple has
>> forwarding the commands down from vtpm to manager to tpm, you'll need
to
>> be more careful to ensure the auth sessions are maintained as the
client
>> expects.
>
>Which commands are you for example forwarding to the hardware TPM? Are
you rooting your key tree to the SRK of
>the hardware TPM?

The current implementation does not forward any commands to the TPM,
however, if one wanted too, you could write the TPM code such that
rather than using openssl for generating key, you called the TPM to
generate keys. Now, my comment about forwarding was that you will not be
able to just forward commands to use these keys down to the TPM. Rather
the vtpm would share an OIAP session with the application in the guest.
The vtpms handles checking that the TPM_Unbind for example is ok. Then
the vtpm makes a separate request down to the TPM to request that the
key owned by the vtpm that resides in the tpm be used to decrypt some
data (that happened to originate from a guest).

-Vinnie

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
Reply | Threaded
Open this post in threaded view
|

RE: Run vTPM in its own VM?

Stefan Berger
In reply to this post by Scarlata, Vincent R

"Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> Sent: Friday, September 15, 2006 9:13 AM
> To: Stefan Berger
> Cc: Scarlata, Vincent R; [hidden email]
> 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:[hidden email]]
> Sent: Freitag, 15. September 2006 12:09
> To: Fischer, Anna
> Cc: Scarlata, Vincent R; [hidden email]
> Subject: RE: [Xense-devel] Run vTPM in its own VM?
>
>
> "Fischer, Anna" <[hidden email]> 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:[hidden email]]
> > Sent: Freitag, 15. September 2006 00:56
> > To: Scarlata, Vincent R
> > Cc: Fischer, Anna; [hidden email]
> > Subject: RE: [Xense-devel] Run vTPM in its own VM?
> >
> >
> > "Scarlata, Vincent R" <[hidden email]> 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:[hidden email]]
> > > Sent: Thursday, September 14, 2006 1:19 PM
> > > To: Scarlata, Vincent R
> > > Cc: Fischer, Anna; [hidden email]
> > > 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" <[hidden email]> 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:[hidden email]]
> > > > Sent: Thursday, September 14, 2006 12:53 PM
> > > > To: Scarlata, Vincent R
> > > > Cc: Fischer, Anna; [hidden email]; xense-devel-
> > > > [hidden email]
> > > > 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
> > > >
> > > > [hidden email] 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:[hidden email]]
> > > > > Sent: Thursday, September 14, 2006 10:27 AM
> > > > > To: Scarlata, Vincent R; [hidden email]
> > > > > 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:[hidden email]]
> > > > > Sent: Donnerstag, 14. September 2006 17:59
> > > > > To: Fischer, Anna; [hidden email]
> > > > > 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: [hidden email]
> > > > > [mailto:[hidden email]] On Behalf Of Fischer,
> > > > > Anna
> > > > > Sent: Thursday, September 14, 2006 2:01 AM
> > > > > To: [hidden email]
> > > > > 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
> > > > > [hidden email]
> > > > > http://lists.xensource.com/xense-devel
> > > > >
> > > > > _______________________________________________
> > > > > Xense-devel mailing list
> > > > > [hidden email]
> > > > > http://lists.xensource.com/xense-devel

_______________________________________________
Xense-devel mailing list
[hidden email]
http://lists.xensource.com/xense-devel
12