|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xense-devel] Run vTPM in its own VM?
"Fischer, Anna" <anna.fischer@xxxxxx> wrote on 09/15/2006 03:06:25 AM: > Decoupling completely from the vTPM manager would also cut the > connection to the hardware TPM. I.e. the vTPMs state is protected by > the hardware TPM (using the vTPM manager). Even though a link to the > physical TPM might not be necessary for all kind of scenarios, it > makes things like migrating a vTPM much more secure. The vTPM > manager will be the right place for managing this linking, as it > already uses the physical TPM for some protection. > It's not clear to me what the vTPM manager does once a domain has been started or is running? What is it's involvement in migration? Particularly in this architecture I had the impression one was going to migrate two virtual machines between two pysical machines. Stefan > Anna > > ________________________________________ > From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] > Sent: Freitag, 15. September 2006 00:56 > To: Scarlata, Vincent R > Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Xense-devel] Run vTPM in its own VM? > > > "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx> wrote on > 09/14/2006 05:01:58 PM: > > > The simple case is that all the DomUvTPM domains are the same, and > > therefore have the same measurement. (Note these should be single > > app domains where the only thing in them is a kernel, vtpm, and the > > supporting libraries). Then the measurement of all the code in this > > domain goes in a PCR in the real TPM. > > > > I don't follow your question about the 2 vTPMs in Dom0 though. Can > > you elaborate? > > You are right, it does not make sense to spawn 2 new virtual TPM > instances for your virtual TPM domains. You would measure the kernel > and initrd of the vTPM domain into the hardware TPM and not care at > the level of application runtime measurements taken *inside* a vTPM domain. > > Regarding the model below. Why do you still need the vtpm_managerd > in dom-0? Isn't access to persistent storage for the vTPM-hosting > domain sufficient so the vTPM can serialize and deserialize its > state when need? If you shut down the vTPM-hosting domain one could > use the existing shutdown mechanism ('shutdown' is launched) to > notify the vTPM to serialize its state to persistent storage. > > Stefan > > > > > > -Vinnie > > > > From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] > > Sent: Thursday, September 14, 2006 1:19 PM > > To: Scarlata, Vincent R > > Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx > > Subject: RE: [Xense-devel] Run vTPM in its own VM? > > > > > The question then is where to these vTPM-hosting domains stick their > > measurements into? I guess you will have to spawn 2 virtual TPM > > instances in domain-0 to give those domains vTPM access. > > > > -- Stefan > > > > "Scarlata, Vincent R" <vincent.r.scarlata@xxxxxxxxx> wrote on > > 09/14/2006 03:59:27 PM: > > > > > Current, I guess they are "trusted," but this is an artifact of Xen > > > not yet having a measurement infrastructure for measuring domains > > > that get launched. It is not the intention to have these domains be > > > implicitly trusted. > > > > > > -Vinnie > > > > > > From: Stefan Berger [mailto:stefanb@xxxxxxxxxx] > > > Sent: Thursday, September 14, 2006 12:53 PM > > > To: Scarlata, Vincent R > > > Cc: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx; xense-devel- > > > bounces@xxxxxxxxxxxxxxxxxxx > > > Subject: RE: [Xense-devel] Run vTPM in its own VM? > > > > > > > > Are DomU1vTPM and DomU2vTPM 'trusted' or are these domains also > > > implementing a transitive trust model with integrity measurements > > > taken inside of them? > > > > > > -- Stefan > > > > > > xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/14/2006 02:30:40 PM: > > > > > > > No, there is only 1 vtpm_manager per platform. As you noted the vTPMs > > > > have a VTPM_MULTI_VM switch. This switch does 2 things. 1) determines if > > > > it reads vTPM commands from a backend or from a FIFO, and 2) if it sends > > > > vtpm control commands to the manager via a tpm frontend or another FIFO. > > > > > > > > So in multivm mode, it looks like the following (which will either clear > > > > things up, or completely confuse them). > > > > > > > > |----- DomU1vTPM ---| |----- DomU1 ----| > > > > /--> FE ~ vtpmd ~ BE <---> FE ~ vtpm drv | > > > > |----- Dom 0 ------| | |-------------------| |----------------| > > > > vtpm_managerd ~ BE <--+ > > > > | |----- DomU2vTPM ---| |----- DomU2 ----| > > > > \--> FE ~ vtpmd ~ BE <---> FE ~ vtpm drv | > > > > |-------------------| |----------------| > > > > > > > > > > > > ^ ^ > > > > | | > > > > save/load cmds tpm cmds > > > > > > > > > > > > The vtpm still has this code in it. The missing code is in the manager. > > > > To support both models the manager had become very complex. Inthe multi > > > > vm case, only control commands came in. In the single vm case, the > > > > manager received tpm commands or control commands (open/close vtpm), > > > > handle the control commands and forward tpm commands to a vtpm, while > > > > accepting control commands (save/load nv) on a different channel. This > > > > was all done through 1 command handler with a mess of #ifdefs. > > > > > > > > I rewrote the handler routines and threading routines to be more > > > > generalized. Now everything is mode agnostic to the number of vms except > > > > manager/vtpmd.c. This file defines the necessary threads, FIFO, and > > > > handlers instances. The current file is a couple hundred lines and sets > > > > everything up for single vm. I plan on writing another vtpmd.c which > > > > sets the manager up for multivm mode. I will then use some sort of a > > > > selector to determine which file to compile based on your mode or maybe > > > > build 2 apps. This is why I call it incomplete. > > > > > > > > -Vinnie > > > > > > > > -----Original Message----- > > > > From: Fischer, Anna [mailto:anna.fischer@xxxxxx] > > > > Sent: Thursday, September 14, 2006 10:27 AM > > > > To: Scarlata, Vincent R; Xense-devel@xxxxxxxxxxxxxxxxxxx > > > > Subject: RE: [Xense-devel] Run vTPM in its own VM? > > > > > > > > Thanks for your reply. > > > > > > > > But do I understand it correctly that in your design you will have a > > > > vTPM manager running in each vTPM BE domain? And you have the vTPM then > > > > talking again through FIFOs to the vTPM manager who talks to the BE? > > > > > > > > However, the code seems to be designed so that the vTPMs talk directly > > > > to the BE. Is that what you mean with that the code for this > > > > configuration is broken? According to the currently implemented design I > > > > don't see how such a direct communication can work as for example > > > > capabilities like saving and loading NVRAM won't work without having the > > > > vTPM manager in between, right? > > > > > > > > Anna > > > > > > > > -----Original Message----- > > > > From: Scarlata, Vincent R [mailto:vincent.r.scarlata@xxxxxxxxx] > > > > Sent: Donnerstag, 14. September 2006 17:59 > > > > To: Fischer, Anna; Xense-devel@xxxxxxxxxxxxxxxxxxx > > > > Subject: RE: [Xense-devel] Run vTPM in its own VM? > > > > > > > > Sorry Anna, the documentation is both slightly out of date, and slightly > > > > ahead of its time. :-) > > > > > > > > The vtpm manager was architected to allows each vtpm instance to run in > > > > its own VM, but during the last restructuring of the code, support for > > > > this configuration was broken. It's now incomplete. Due to other > > > > commitments, I won't be able to get back to this immediately, I hope to > > > > submit a patch to re-enable this config options within a month-ish. > > > > > > > > The way it looked and will look again is the following. A standard > > > > config would be a Dom0, DomU1 guest, DomU1vTPM vtpm domain, ... DomUn, > > > > DomUnvTPM. DomU1 has a tpm FE, for which DomU1vTPM has the BE.Similarly > > > > DomU2 has a tpm FE, for which DomU2vTPM has the BE. This allows direct > > > > communication between the DomU and it's vTPM, as you mention below. Then > > > > all the DomU*vTPM domains have tpm FEs, for which the domain housing the > > > > vtpm manager is the BE. By default this is Dom0, but provided that the > > > > tpm device can be assigned to a different domain, this can be put in any > > > > domain. The vtpm_manager's domain has the tpm driver. > > > > > > > > This is a little heavier weight than running everything in dom0, but it > > > > removes the manager from being a bottle neck in tpm access, since all > > > > DomUs can access their vTPMs simultaneously (though the manager can > > > > still only handle 1 vtpm request at a time to save internal states). > > > > Also isolation between vtpms is established. > > > > > > > > Do you need this functionality, or are you just doing thought > > > > experiments? > > > > > > > > Hopes this answers your questions, > > > > > > > > -Vinnie Scarlata > > > > Trusted Platform Lab > > > > Corporate Technology Group > > > > Intel Corporation > > > > > > > > -----Original Message----- > > > > From: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx > > > > [mailto:xense-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Fischer, > > > > Anna > > > > Sent: Thursday, September 14, 2006 2:01 AM > > > > To: Xense-devel@xxxxxxxxxxxxxxxxxxx > > > > Subject: [Xense-devel] Run vTPM in its own VM? > > > > > > > > The README of the current Xen unstable version says that setting > > > > VTPM_MULTI_VM allows running each vTPM in its own VM. However,compiling > > > > with this option doesn't work on my machine and the code doesn't seem to > > > > be complete for this option. > > > > > > > > Did I miss to configure something or is the current implementation in > > > > Xen not really ready for running a vTPM in a separate VM? > > > > > > > > Can you explain to me how a communication will look like for the planned > > > > implementation in Xen? Will all communication continue to go through the > > > > vTPM manager and the vTPM manager talks to a kind of FE that transmits > > > > TPM commands to a BE running in a separate domain? Or is it possible to > > > > set up direct connections between a user domain TPM FE and the vTPM > > > > running in an isolated VM? > > > > > > > > Regards, > > > > Anna > > > > > > > > _______________________________________________ > > > > Xense-devel mailing list > > > > Xense-devel@xxxxxxxxxxxxxxxxxxx > > > > http://lists.xensource.com/xense-devel > > > > > > > > _______________________________________________ > > > > Xense-devel mailing list > > > > Xense-devel@xxxxxxxxxxxxxxxxxxx > > > > http://lists.xensource.com/xense-devel _______________________________________________ Xense-devel mailing list Xense-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xense-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |