[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

 


Rackspace

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