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

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

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


 


Rackspace

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