From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: xc_evtchn_status fails with EFAULT on HVM, the same on PV works Date: Tue, 17 Jan 2017 00:06:57 +0100 Message-ID: <20170116230657.GI5268@mail-itl> References: <20170113183239.GK5268@mail-itl> <20170113185922.GL1341@mail-itl> <0c47b88f-4130-a9b8-cf93-89ae03b25dab@citrix.com> <20170113194052.GB18728@mail-itl> <20170113203223.GO1341@mail-itl> <8892ce3d-25b0-338f-986f-c1bddf65ee3d@citrix.com> <20170114025227.GR5268@mail-itl> <587CC80702000078001306CE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7617603828648055836==" Return-path: In-Reply-To: <587CC80702000078001306CE@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: Andrew Cooper , xen-devel List-Id: xen-devel@lists.xenproject.org --===============7617603828648055836== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l7itP/1EBO9PCc/O" Content-Disposition: inline --l7itP/1EBO9PCc/O Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2017 at 05:17:59AM -0700, Jan Beulich wrote: > >>> On 14.01.17 at 03:52, 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.) > >>=20 > >> 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. > >>=20 > >> 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. > >>=20 > >> 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".=20 > >=20 > > 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? >=20 > There are two additional things to consider here: >=20 > 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). >=20 > 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"? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki 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? --l7itP/1EBO9PCc/O Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYfVISAAoJENuP0xzK19cskvMH/3t2y6vf+dM7NeXpZJGrZj9M OsVRn1pvNMf69gKnKQNr3MIT72G2A+hyM9esJuM+03cfwHDXyS9cdCjo2jhGzM/6 4R+lANNdwT90bFHRL1UpBihwBeyJ0zsDHTm9ckVkpz/uiAbHBEi3oKkz1jiZXO7v k8L+BL0Bc7J7iM8Gd+STGW5E9Epqk0onfhbjmaeFvuQep4L+g7xfc0Uqq2S7rHGp 4q2VXYhpxOaISQDS4wbypkWJt10BlHIv3yXb5TjF9YSq95mW7uR1yyL8Dwu6I5RY xv/7LIVWsRz41E7fm/12RNiGffVybbDooR2xqnHPn+ezQa6fIFYSuFXS2UyTrUA= =krKK -----END PGP SIGNATURE----- --l7itP/1EBO9PCc/O-- --===============7617603828648055836== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7617603828648055836==--