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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 01/08/2015 11:49 AM, Xu, Quan wrote:
> > -----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'.
I would have this as a parameter in describing the vTPM device, similar to
how the file name of the disk images are described.  The actual command line
or configuration for QEMU might use a domain name instead of a domain ID.  I
would check to see how disk or network backend domains are handled (I assume
they are supported by qemu-in-dom0; I don't recall testing that setup myself).

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

--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel