[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Enabling #VE for a domain from dom0
On 24/02/17 14:42, Vlad-Ioan TOPAN wrote: >> #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? /sigh The underlying hypercall is HVMOP_altp2m, which is supposed to have a stable ABI, as it is guest visible. However, it has a HVMOP_ALTP2M_INTERFACE_VERSION wedged in there, which is unacceptable, and broken, as it cannot be used correctly from within a guest. The only option we have to is freeze HVMOP_ALTP2M_INTERFACE_VERSION at its current value and force it to never change. I am sorry for not having picked up on this point during review of the series several releases ago. However, for your purposes, you don't need libxc. You should just be able to make HVMOP hypercalls directly to set up #VE from within the guest. > 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. suppress #VE has a negative meaning. Once #VE is enabled, all frames need SVE for Xen to continue getting EPT_VIOLATION vmexits per usual. It is only whitelisted frames which should have SVE cleared on them. Having said that, by the time you have cooperation between several domains, I don't see a reason for excluding a remote domain updating SVE. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |