Re: [Xen-devel] FW: [PATCH 1/6] vTPM: event channel bind interdomain with para/hvm virtual machine

["Xu, Quan" <quan.xu@xxxxxxxxx>]

> -----Original Message-----
> From: Xu, Quan
> Sent: Friday, November 07, 2014 12:56 AM
> To: Daniel De Graaf
> Cc: samuel.thibault@xxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxx; Xu, Quan
> Subject: RE: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> para/hvm virtual machine
> 
> 
> 
> > -----Original Message-----
> > From: Daniel De Graaf [mailto:dgdegra@xxxxxxxxxxxxx]
> > Sent: Friday, October 31, 2014 2:29 AM
> > To: Xu, Quan
> > Cc: samuel.thibault@xxxxxxxxxxxx
> > Subject: Re: FW: [PATCH 1/6] vTPM: event channel bind interdomain with
> > para/hvm virtual machine
> >
> > On 10/30/2014 11:06 AM, Xu, Quan wrote:
> > [...]
> > >> +   domid = (domtype == T_DOMAIN_TYPE_HVM) ? 0 : tpmif->domid;
> >
> > This seems to preclude the use of stub domain device models for HVM
> > domains; in that case, the event channel/grant page would need to be
> > mapped to the stub domain.  I think it may be better to pass in the
> > target domain ID in xenstore rather than overriding it based on PV vs
> > HVM.  In any case, in order to support HVM domains with PV drivers, an
> > additional backend/frontend pair is required for QEMU rather than
> > redirecting the existing vTPM to the device model's domain.
> >
> 
> Thanks Graaf.
> HVM domains are still runing tpm_tis.ko driver or Windows TPM 1.2 driver,
> as they run on physical machine.
> When I tried to enable vTPM for HVM domains, I pass in the target domain
> ID in XenStore too, but it is not working. because the vTPM frontend is
> implemented in QEMU.
> 
> For HVM domains, QEMU is running in Dom0 as usual. So the domid shoud
> be 0.
> some requirement from local ISV, they need vTPM for unmodified domain in
> virtual desktop infrastructure.
> 
> > I would suggest attaching the vTPM directly to domain 0, but that
> > would cause the vTPM to be picked up by the dom0 kernel instead of by
> > QEMU, so that is not helpful.  If there is an existing solution for
> > disk or network driver domains attached to HVM, the solution used
> > there should be mirrored here; I have not looked to see how (or if) it is
> solved in those drivers.
> >
> In this patch series, It is a solution for HVM domains.
> I am very pleased if we can collaborate to enhance / modify it in coming Xen
> version(4.7 or ..)
> 
> > A solution needs to be able to handle:
> >
> > 1. Existing PV domains
> 
> Yes, it is compatible with pv domains or non-vtpm domains.
> 
> > 2. HVM domain using TIS MMIO and no stubdom - without special casing
> > dom0 3. HVM domain using TIS MMIO via a stubdom
> 
> Now the TIS MMIO is registered in Qemu.
> 
> 
> >4. Linux HVM domain
> > with the PV vTPM driver (talks directly to the vTPM)
> 
> I did not have available physical machine. It is still building the domu 
> kernel
> with PV vTPM driver.
> I guess, there may be /dev/tpm0 and /dev/tpm1 I will share the test result
> tomorrow

Graaf, the test result:
1. tpm_tis.ko / xen_tpmfront.ko are both enabled. 
  PV vTPM driver is running in guest domain.
# lsmod | grep xen_tpmfront
xen_tpmfront  6202  0

vtpm backend in xenstore:
backend = ""
    vtpm = ""
     9 = ""
      0 = ""
        [...]

Vtpm frontend in xenstore:
    vtpm = ""
     0 = ""
      [...]
      domain-type = "1"
      [...]
the domain type is 1, so HVM frontend vTPM driver is running.  
(  #define T_DOMAIN_TYPE_HVM 1
  #define T_DOMAIN_TYPE_PV  2
)




> 
> >
> > Similar to network and disk, when an OS that understands Xen devices
> > finds a vTPM interface, it should detach/ignore the MMIO TPM interface.
> > The vTPM domain is set up to handle this case: multiple connections to
> > a single vTPM domain are permitted and will all talk to the same TPM
> instance.
> 
> Yes, pv domains and hvm domains can talk to the same TPM instance.
> 
> > Locality restrictions are based on the event channel endpoint, and so
> > will still work even when tpmif->domid is incorrect; this is required
> > to properly implement the DRTM if it is to be emulated.
> 
> 
> Graaf, I will read your suggestion again and again. I have not read your new
> feature in Docs/misc/vtpm-platforms.txt.
> I am still committing some other features, And dealing with some review
> comments.
> BTW, could you share some document about disk_io in stubdom/vtpmmgr.
> I enabled vtpmmgr on TPM 2.0 based on Xen 4.3.0. try to get rooted trust on
> TPM 2.0 .
> it is not working now, as you changed disk io.
> 
> 
> 
> >
> > --
> > Daniel De Graaf
> > National Security Agency
> 
> 
> Thanks
> Quan Xu

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