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

Re: [Xen-devel] Enabling #VE for a domain from dom0



> #VE, by design, raises an exception in non-root context, without
> breaking out to the hypervisor.
> 
> The vcpu in question needs to set up a suitable #VE handler, so it is
> not safe for an external entity to chose when a vcpu should start
> receiving #VE's.

The problem is that from a security solution standpoint, it isn't
feasible in a Windows guest to use libxc to enable #VE. As it is
implemented, libxc is required to allow sharing a structure between the
guest and the host; the structure only contains the gfn of the #VE page
and the domain id/vcpu id, which are useless since it can only be
enabled on the current VCPU. Would a patch providing a simpler VMCALL
(without sharing structures, only passing the gfn) to enable #VE be
acceptable?

Is there any reason for the other check I've mentioned, performed when
setting the "suppres #VE" bit in PTEs? Unsuppressing #VEs for a page
will only do anything if the guest has already enabled #VE, so the
previous issue doesn't apply in this case.

Thank you for the prompt answer!
--
Vlad-Ioan TOPAN

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

 


Rackspace

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