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: 1432 bytes --]

[resurrecting old thread...]

On Mon, Jan 16, 2017 at 11:41:55PM +0000, Andrew Cooper wrote:
> On 16/01/2017 23:06, Marek Marczykowski-Górecki wrote:
> > On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote:
> >> 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@.

Should I submit it?

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

How to disable SMAP for selected guests only?

-- 
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