Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote:
> On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
>>>>> On 14.01.17 at 03:52, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>> On Sat, Jan 14, 2017 at 01:47:49AM +0000, Andrew Cooper wrote:
>>>> In a native situation, SMAP raises #PF if hardware tries to follow a
>>>> user pointer outside of an area whitelisted by the kernel.  (The
>>>> copy_*_guest path suppresses #PF, opting instead to return -EFAULT.)
>>>>
>>>> The choice of supervisor vs user in a pagewalk is a single bit, and Xen
>>>> (for better or worse, but realistically as a consequence of SMAP being
>>>> ~10 years younger than HVM guests) accesses pointers from hypercalls as
>>>> a supervisor entity when walking the pagetables.  The key point here is
>>>> that Xen must emulate the hardware pagewalker when trying to find the
>>>> data being pointed to.
>>>>
>>>> If Xen has a bug causing spurious accesses to HVM guests, then all bets
>>>> are already off wrt memory corruption, because real hardware isn't used
>>>> to make the access.
>>>>
>>>> As indicated before, we could deliberately break the Xen pagewalker to
>>>> ignore SMAP.  However, that would be identical to "pretend the guest
>>>> actually whitelisted this access". 
>>> I think there is important difference between "whitelist all accesses
>>> to guest user memory for the hypercall time" vs "whitelist accesses done
>>> through copy_from_guest/copy_to_guest only". If I understand correctly
>>> above description, modifying privcmd_call would also suppress #PF when
>>> Xen would be tricked to access guest memory outside of copy_*_guest. Am
>>> I missing something?
>> There are two additional things to consider here:
>>
>> 1) For HVM guests, Xen can't access guest memory unintentionally,
>> as (other than in the PV case) virtual address spaces are distinct.
> Good point.
>
>> 2) When the guest issues stac()/clac(), it indicates to Xen _its own_
>> intended view, without affecting Xen's. That is, as soon as hypervisor
>> context is being entered again, SMAP protection would be in effect
>> again (albeit as per point 1 guarding only against accessing PV guest
>> mappings).
>>
>> So the driver adjustment suggested by Andrew has an effect on only
>> page walks done by Xen during copy_{to,from}_guest(), but not on
>> actual memory accesses.
> Ok, so indeed the kernel patch makes the most sense here. Is the change
> in this shape (if works - I'll test it shortly) good to include
> upstream, or is it "ugly hack"?

If it works (which I suspect it will), then it will be the correct
proper upstream fix, and will of course CC stable@.

In the meantime until it percolates into downstream kernels, disabling
SMAP for affected guests is probably the best stopgap solution.

~Andrew

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