[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [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

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

   * This stub domain will not have domain 0; the vTPM must bind to
     domain ID.
   * It is possible to use the native TPM driver for the stub domain (which
     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
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

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 

I like the /local/domain/0/frontend/* path better than my initial qemu 
but I think the domain ID used should be the domain ID of the vTPM domain, 
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 
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 

/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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.