> -----Original Message----- > From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > Sent: Thursday, January 08, 2015 11:55 PM > To: Xu, Quan; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > Subject: Re: [PATCH v2 1/5] vTPM: event channel bind interdomain with > para/hvm virtual machine > > On 01/08/2015 03:20 AM, Xu, Quan wrote: > > > > > >> -----Original Message----- > >> From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > >> Sent: Wednesday, January 07, 2015 3:47 AM > >> To: Xu, Quan; xen-devel@lists.xen.org > >> Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > >> Subject: Re: [PATCH v2 1/5] vTPM: event channel bind interdomain with > >> para/hvm virtual machine > >> > >> On 01/06/2015 11:46 AM, Xu, Quan wrote: > >>>> -----Original Message----- > >>>> From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] On 12/30/2014 > >>>> 11:44 PM, Quan Xu wrote:[...] > >>>>> diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c > >>>> [...] > >>>>> + domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid; > >>>> > >>>> Unless I'm missing something, this still assumes that the HVM > >>>> device model is located in domain 0, and so it will not work if a > >>>> stub domain is used for qemu. > >>>> > >>> > >>> QEMU is running in Dom0 as usual, so the domid is 0. > >>> as similar to Linux PV frontend driver, this frontend driver is > >>> enabled in > >> QEMU. > >> > >> This is a valid configuration of Xen and these patches do suffice to > >> make it work. I am trying to ensure that an additional type of guest > >> setup will also work with these patches. > >> > >> A useful feature of Xen is the ability to execute the QEMU device > >> model in a domain instead of a process in dom0. When combined with > >> driver domains for devices, this can significantly reduce both the > >> attack surface of and amount of trust required of domain 0. > >> > >>> Any doubt, feel free to contact. I will try my best to explain. I > >>> think your > >> suggestions are very helpful in previous email(Oct. 31th, 2014. > >>> ' Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with > >>> para/hvm virtual machine') Maybe this is still a vague description > >>> :( > >> > >> This is accurate but possibly incomplete. > >> > >> This is my current understanding of the communications paths and > >> support for vTPMs in Xen: > >> > >> Physical TPM (1.2; with new patches, may also be 2.0) > >> | > >> [MMIO pass-through] > >> | > >> vtpmmgr domain > >> | > >> [minios tpmback/front] ----- ((other domains' vTPMs)) > >> | > >> vTPM domain (currently always emulates a TPM v1.2) > >> | > >> [minios tpmback]+----[Linux tpmfront]-- PV Linux domain (fully working) > >> | \ > >> | +--[Linux tpmfront]-- HVM Linux with optional PV > >> drivers > >> | \ > >> [QEMU XenDevOps] [minios or Linux tpmfront] > >> | | > >> QEMU dom0 process QEMU stub-domain > >> | | > >> [MMIO emulation] [MMIO emulation] > >> | | > >> Any HVM guest Any HVM guest > >> > > > > Great, good architecture. The following part is not put into account in my > previous design. > > > > [minios or Linux tpmfront] > > | > > QEMU stub-domain > > | > > [MMIO emulation] > > | > > Any HVM guest > > > > Thanks Graaf for sharing your design. > >> > >> The series you are sending will enable QEMU to talk to tpmback directly. > >> This is the best solution when QEMU is running inside domain 0, > >> because it is not currently a good idea to use Linux's tpmfront > >> driver to talk to each guest's vTPM domain. > >> > >> When QEMU is run inside a stub domain, there are a few more things to > >> consider: > >> > >> * This stub domain will not have domain 0; the vTPM must bind to > >> another > >> domain ID. > >> * It is possible to use the native TPM driver for the stub domain > >> (which may > >> either run Linux or mini-os) because there is no conflict with a real > TPM > >> software stack running inside domain 0 > >> > >> Supporting this feature requires more granularity in the TPM backend > >> changes. > >> The vTPM domain's backend must be able to handle: > >> > >> (1) guest domains which talk directly to the vTPM on their own behalf > >> (2) QEMU processes in domain 0 > >> (3) QEMU domains which talk directly to the vTPM on behalf of a > >> guest > >> > >> Cases (1) and (3) are already handled by the existing tpmback if the > >> proper domain ID is used. > >> > >> Your patch set currently breaks case (1) and (3) for HVM guests while > >> enabling case (2). An alternate solution that does not break these > >> cases while enabling case (2) is preferable. > >> > >> My thoughts on extending the xenstore interface via an example: > >> > >> Domain 0: runs QEMU for guest A > >> Domain 1: vtpmmgr > >> Domain 2: vTPM for guest A > >> Domain 3: HVM guest A > >> > >> Domain 4: vTPM for guest B > >> Domain 5: QEMU stubdom for guest B > >> Domain 6: HVM guest B > >> > >> /local/domain/2/backend/vtpm/3/0/*: backend A-PV > >> /local/domain/3/device/vtpm/0/*: frontend A-PV > >> > >> /local/domain/2/backend/vtpm/0/3/*: backend A-QEMU > >> /local/domain/0/qemu-device/vtpm/3/*: frontend A-QEMU (uses > >> XenDevOps) > > > > I think '/local/domain/0/frontend/vtpm/3/0' is much better. Similar as > > some backend in Qemu running in Domain-0, it always Stores as > '/local/domain/0/backend/qdisk/1 .etc'. I will also modify QEMU code to make > '/local/domain/0/frontend/DEVICE' > > As a general design for general QEMU frontend running in Domain-0. > > > > For this example, > > Domain 0: runs QEMU for guest A > > Domain 1: vtpmmgr > > Domain 2: vTPM for guest A > > Domain 3: HVM guest A > > > > I will design XenStore as following: > > > > ## XenStore >> ### > > local = "" > > domain = "" > > 0 = "" > > frontend = "" > > vtpm = "" > > 3 = "" > > 0 = "" > > backend = "/local/domain/2/backend/vtpm/3/0" > > backend-id = "2" > > state = "*" > > handle = "0" > > ring-ref = "*" > > event-channel = "*" > > feature-protocol-v2 = "1" > > backend = "" > > qdisk = "" > > [...] > > console = "" > > vif = "" > > [...] > > 2 = "" > > [...] > > backend = "" > > vtpm = "" > > 3 = "" > > 0 = "" > > frontend = "/local/domain/0/frontend/vtpm/3/0" > > frontend-id = "0" ('0', frontend is running in Domain-0) > > [...] > > 3 = "" > > [...] > > device = "" (frontend device, the backend is running in QEMU/.etc) > > vkbd = "" > > [...] > > vif = "" > > [...] > > ## XenStore << ## > > > > Then, the source code can read xenStore to get frontend-id or frontend > directly. > > If you agree with it, I will modify source code to align with above XenStore > design. > > I like the /local/domain/0/frontend/* path better than my initial qemu > suggestion, but I think the domain ID used should be the domain ID of the vTPM > domain, similar to how backends for the qemu stubdom are done. In this > example, the paths would be "/local/domain/0/frontend/vtpm/2/0" and > "/local/domain/2/backend/vtpm/0/0".
Thanks Graaf. Domain 0: runs QEMU for guest A Domain 1: vtpmmgr Domain 2: vTPM for guest A Domain 3: HVM guest A /local/domain/0/frontend/vtpm/2/0 /local/domain/2/backend/vtpm/0/0 I have one question. How does Domain 3 read/write XenStore? Such as /local/domain/0/frontend/vtpm/2/* In QEMU frontend, it can get Domain ID -- '3', but it does know the backend domain ID is '2'. > This avoids introducing a dependency on the domain ID of the guest in a > connection that does not directly involve that domain. If a guest ever needs > two vTPMs or multiple guests share a vTPM, this method of constructing the > paths will avoid unneeded conflicts (though I don't expect either of these > situations to be normal). > > >> > >> /local/domain/4/backend/vtpm/5/0/*: backend B-QEMU > >> /local/domain/5/device/vtpm/0/*: frontend B-QEMU > >> > >> /local/domain/4/backend/vtpm/6/0/*: backend B-PV > >> /local/domain/6/device/vtpm/0/*: frontend B-PV > >> > >> Connections A-PV, B-PV, and B-QEMU would be created in the same > >> manner as the existing "xl vtpm-attach" command does now. If the HVM > >> guest is not running Linux with the Xen tpmfront.ko loaded, the A-PV > >> and B-PV devices will remain unconnected; this is fine. > >> > >> Connection A-QEMU has a modified frontend state path to prevent Linux > >> from attaching its own TPM driver to the guest's TPM. > > > > Your design is working. For this case, > > > > Domain 4: vTPM for guest B > > Domain 5: QEMU stubdom for guest B > > Domain 6: HVM guest B > > > > As my understanding, Xl tools will create Donmain 5 as a PV domain. It > > works as Existing solutions. I think it can extend with libvirt too. > > You can make Domain 6 connected Domain 5 by QEMU command line > options, > > and it Is quite similar to TPM passthrough. > > Yes, this setup should be possible today once the proper device configuration > is > added to the QEMU configuration. > > > So in this case, we don't care '-PV' or '-Qemu'. also '-pv'/'-QEMU' are > confusing in XenStore. > > Yes; this was one reason I did not want to introduce an "HVM" type in > Xenstore. > Hope someone can implement it...:) Intel Quan Xu > -- > Daniel De Graaf > National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
