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

> 
> /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. 
So in this case, we don't care  '-PV' or '-Qemu'. also '-pv'/'-QEMU' are 
confusing in XenStore.


>This requires a few
> changes:
> libxl must support changing the frontend path; this is similar to how disk
> backend supports both qdisk and vbd (and others), but instead changes the
> path for the frontend.  The minios backend also needs to change the sscanf
> in parse_eventstr to something like
> "/local/domain/%u/%*[^/]/vtpm/%u/%40s".
> 
> In any case, the vTPM does not need to know if the guest is PV, HVM, or
> PVH.


Correct me, if I am wrong.  

Thanks 
Quan

> --
> Daniel De Graaf
> National Security Agency

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