[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |