Re: xc_evtchn_status fails with EFAULT on HVM, the same on PV works

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2697 bytes --]

On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> >>> On 14.01.17 at 03:52, <marmarek@invisiblethingslab.com> 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"?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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