Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
Also CC Stefan Berger.
> >> 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, si
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: xen-devel-boun...@lists.xen.org > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan > Sent: Friday, January 09, 2015 9:25 AM > To: Daniel De Graaf; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain > with para/hvm virtual machine > > > > > -Original Message- > > From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > > Sent: Friday, January 09, 2015 1:48 AM > > To: Xu, Quan; xen-devel@lists.xen.org > > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > > 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:dgde...@tycho.nsa.gov] > > >> Sent: Thursday, January 08, 2015 11:55 PM > > >> To: Xu, Quan; xen-devel@lists.xen.org > > >> Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > > >> 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:dgde...@tycho.nsa.gov] > > >>>> Sent: Wednesday, January 07, 2015 3:47 AM > > >>>> To: Xu, Quan; xen-devel@lists.xen.org > > >>>> Cc: samuel.thiba...@ens-lyon.org; > > >>>> stefano.stabell...@eu.citrix.com > > >>>> 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:dgde...@tycho.nsa.gov] 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] > > >>>>
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > Sent: Friday, January 09, 2015 1:48 AM > To: Xu, Quan; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > 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:dgde...@tycho.nsa.gov] > >> Sent: Thursday, January 08, 2015 11:55 PM > >> To: Xu, Quan; xen-devel@lists.xen.org > >> Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > >> 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:dgde...@tycho.nsa.gov] > Sent: Wednesday, January 07, 2015 3:47 AM > To: Xu, Quan; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > 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:dgde...@tycho.nsa.gov] 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
Re: [Xen-devel] [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:dgde...@tycho.nsa.gov] Sent: Thursday, January 08, 2015 11:55 PM To: Xu, Quan; xen-devel@lists.xen.org Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com 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:dgde...@tycho.nsa.gov] Sent: Wednesday, January 07, 2015 3:47 AM To: Xu, Quan; xen-devel@lists.xen.org Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com 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:dgde...@tycho.nsa.gov] 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 runni
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > Sent: Thursday, January 08, 2015 11:55 PM > To: Xu, Quan; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > 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:dgde...@tycho.nsa.gov] > >> Sent: Wednesday, January 07, 2015 3:47 AM > >> To: Xu, Quan; xen-devel@lists.xen.org > >> Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > >> 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:dgde...@tycho.nsa.gov] 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 exam
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:dgde...@tycho.nsa.gov] Sent: Wednesday, January 07, 2015 3:47 AM To: Xu, Quan; xen-devel@lists.xen.org Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com 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:dgde...@tycho.nsa.gov] 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 = ""
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > Sent: Wednesday, January 07, 2015 3:47 AM > To: Xu, Quan; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > 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:dgde...@tycho.nsa.gov] 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.
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: xen-devel-boun...@lists.xen.org > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Xu, Quan > Sent: Wednesday, January 07, 2015 9:45 AM > To: Samuel Thibault > Cc: Daniel De Graaf; xen-devel@lists.xen.org; stefano.stabell...@eu.citrix.com > Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind > interdomain with para/hvm virtual machine > > > > > -Original Message- > > From: xen-devel-boun...@lists.xen.org > > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Samuel Thibault > > Sent: Wednesday, January 07, 2015 12:57 AM > > To: Xu, Quan > > Cc: Daniel De Graaf; stefano.stabell...@eu.citrix.com; > > xen-devel@lists.xen.org > > Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind > > interdomain with para/hvm virtual machine > > > > Xu, Quan, le Tue 06 Jan 2015 16:46:58 +, a écrit : > > > QEMU is running in Dom0 as usual, so the domid is 0. > > > > One can also run the HVM QEMU inside a stubdomain. > > A good case, thanks Samuel. > Once running the HVM QEMU inside a stubdomain, the domain type is > para-virtualization(T_DOMAIN_TYPE_PV) > > #define T_DOMAIN_TYPE_HVM 1 > #define T_DOMAIN_TYPE_PV 2 > I missed this case, described by Graaf. I have not tried it. ### [...] [minios or Linux tpmfront] | QEMU stub-domain | [MMIO emulation] | Any HVM guest ### Thanks Quan > Thanks > Quan > > > > Samuel > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: xen-devel-boun...@lists.xen.org > [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Samuel Thibault > Sent: Wednesday, January 07, 2015 12:57 AM > To: Xu, Quan > Cc: Daniel De Graaf; stefano.stabell...@eu.citrix.com; xen-devel@lists.xen.org > Subject: Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind > interdomain with para/hvm virtual machine > > Xu, Quan, le Tue 06 Jan 2015 16:46:58 +, a écrit : > > QEMU is running in Dom0 as usual, so the domid is 0. > > One can also run the HVM QEMU inside a stubdomain. A good case, thanks Samuel. Once running the HVM QEMU inside a stubdomain, the domain type is para-virtualization(T_DOMAIN_TYPE_PV) #define T_DOMAIN_TYPE_HVM 1 #define T_DOMAIN_TYPE_PV 2 Thanks Quan > > Samuel > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [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:dgde...@tycho.nsa.gov] 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 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) /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. 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. BTW, professor J. Wang(Wuhan University, China) and I have enabled TPM 2.0 simulator for Linux, Maybe we will try to integrate with vtpm domain to provide TPM 2.0 vtpm function for virtual
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
Xu, Quan, le Tue 06 Jan 2015 16:46:58 +, a écrit : > QEMU is running in Dom0 as usual, so the domid is 0. One can also run the HVM QEMU inside a stubdomain. Samuel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
> -Original Message- > From: Daniel De Graaf [mailto:dgde...@tycho.nsa.gov] > Sent: Tuesday, January 06, 2015 12:06 AM > To: Xu, Quan; xen-devel@lists.xen.org > Cc: samuel.thiba...@ens-lyon.org; stefano.stabell...@eu.citrix.com > Subject: Re: [PATCH v2 1/5] vTPM: event channel bind interdomain with > para/hvm virtual machine > > 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. *ARCHITECTURE* The architecture of stubdom vTPM for HVM virtual machine: ++ | Windows/Linux DomU | ... (tpm_tis.ko) || ^| |v || | Qemu tpm1.2 Tis | (Seabios patch will enable this TPM 1.2 TIS, including ACPI for 0xfed4 -- / register enables) || ^| (Seabios, I did not send out, maybe this is the missed.) |v || | XenStubdoms backend| ++ | ^ (XenStubdoms backend/ XenDevOps are QEMU parts provide the glue for the TPM_TIS(Qemu frontend) to Xen stubdom vTPM domain) v | ++ | XenDevOps | ++ | ^ v | ++ | mini-os/tpmback | 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 :( BTW, professor J. Wang(Wuhan University, China) and I have enabled TPM 2.0 simulator for Linux, Maybe we will try to integrate with vtpm domain to provide TPM 2.0 vtpm function for virtual machine in Q2 or later. Thanks Quan Xu > -- > Daniel De Graaf > National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
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. -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/5] vTPM: event channel bind interdomain with para/hvm virtual machine
Signed-off-by: Quan Xu
---
extras/mini-os/include/tpmback.h | 3 +++
extras/mini-os/tpmback.c | 20 +---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/extras/mini-os/include/tpmback.h b/extras/mini-os/include/tpmback.h
index 4408986..2618098 100644
--- a/extras/mini-os/include/tpmback.h
+++ b/extras/mini-os/include/tpmback.h
@@ -41,6 +41,9 @@
#ifndef TPMBACK_H
#define TPMBACK_H
+#define T_DOMAIN_TYPE_HVM 1
+#define T_DOMAIN_TYPE_PV 2
+
struct tpmcmd {
domid_t domid; /* Domid of the frontend */
uint8_t locality;/* Locality requested by the frontend */
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
index 00b66e8..d76e05e 100644
--- a/extras/mini-os/tpmback.c
+++ b/extras/mini-os/tpmback.c
@@ -555,7 +555,7 @@ int connect_fe(tpmif_t* tpmif)
{
char path[512];
char* err, *value;
- uint32_t domid;
+ uint32_t domid, domtype;
grant_ref_t ringref;
evtchn_port_t evtchn;
@@ -608,14 +608,28 @@ int connect_fe(tpmif_t* tpmif)
}
free(value);
- domid = tpmif->domid;
+ /* get the domain type*/
+ snprintf(path, 512, "%s/domain-type", tpmif->fe_path);
+ if ((err = xenbus_read(XBT_NIL, path, &value))) {
+ TPMBACK_ERR("xenbus_read(%s) Error = %s", path, err);
+ free(err);
+ return -1;
+ }
+ if (sscanf(value, "%d", &domtype) != 1) {
+ TPMBACK_ERR("Non integer value (%s) \n", value);
+ free(value);
+ return -1;
+ }
+
+ printk("domtype = %d \n",domtype);
+ domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
if((tpmif->page = gntmap_map_grant_refs(>pmdev.map, 1, &domid, 0,
&ringref, PROT_READ | PROT_WRITE)) == NULL) {
TPMBACK_ERR("Failed to map grant reference %u/%u\n", (unsigned int)
tpmif->domid, tpmif->handle);
return -1;
}
/*Bind the event channel */
- if((evtchn_bind_interdomain(tpmif->domid, evtchn, tpmback_handler, tpmif,
&tpmif->evtchn)))
+ if((evtchn_bind_interdomain(domid, evtchn, tpmback_handler, tpmif,
&tpmif->evtchn)))
{
TPMBACK_ERR("%u/%u Unable to bind to interdomain event channel!\n",
(unsigned int) tpmif->domid, tpmif->handle);
goto error_post_map;
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
