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: Friday, January 09, 2015 1:48 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/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)

.
Thanks. 
I will also check to see how disk or network backend domains are handled.
Any result, I will send out. 

Quan

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