Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine

["Xu, Quan" <quan.xu@xxxxxxxxx>]

> -----Original Message-----
> From: Daniel De Graaf [mailto:dgdegra@xxxxxxxxxxxxx]
> Sent: Thursday, January 08, 2015 11:55 PM
> To: Xu, Quan; xen-devel@xxxxxxxxxxxxx
> Cc: samuel.thibault@xxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx
> 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:dgdegra@xxxxxxxxxxxxx]
> >> Sent: Wednesday, January 07, 2015 3:47 AM
> >> To: Xu, Quan; xen-devel@xxxxxxxxxxxxx
> >> Cc: samuel.thibault@xxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx
> >> 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:dgdegra@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel