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

--
Daniel De Graaf
National Security Agency

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