From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: x86: PIE support and option to extend KASLR randomization Date: Fri, 6 Oct 2017 12:39:33 +0200 Message-ID: <20171006103933.GA9497__11935.2818503559$1507286446$gmane$org@amd> References: <20170815075609.mmzbfwritjzvrpsn@gmail.com> <20170816151235.oamkdva6cwpc4cex@gmail.com> <20170821133222.2ek6bhqgdeoymxsg@hirez.programming.kicks-ass.net> <20170821142854.dmuusnbc2tsrai3v@hirez.programming.kicks-ass.net> <20170923100029.6nzpui6c3ke76bbs@gmail.com> <20170924223708.GA12616@amd> <20170925073342.2yoghmanhx6c75ho@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4848466927645144709==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e0Q2i-0004D2-Tx for xen-devel@lists.xenproject.org; Fri, 06 Oct 2017 10:39:45 +0000 In-Reply-To: <20170925073342.2yoghmanhx6c75ho@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Ingo Molnar Cc: Nicolas Pitre , Michal Hocko , kvm list , Radim =?utf-8?B?S3LEjW3DocWZ?= , Peter Zijlstra , Catalin Marinas , Christopher Li , Alexei Starovoitov , David Howells , Paul Gortmaker , Peter Foley , "H. Peter Anvin" , Kernel Hardening , Christoph Lameter , Thomas Gleixner , Kees Cook , the arch/x86 maintainers , Herbert Xu , Daniel Borkmann , Matthew Wilcox , Joerg Roedel , "Rafael J . Wysocki" List-Id: xen-devel@lists.xenproject.org --===============4848466927645144709== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon 2017-09-25 09:33:42, Ingo Molnar wrote: >=20 > * Pavel Machek wrote: >=20 > > > For example, there would be collision with regular user-space mapping= s, right?=20 > > > Can local unprivileged users use mmap(MAP_FIXED) probing to figure ou= t where=20 > > > the kernel lives? > >=20 > > Local unpriviledged users can probably get your secret bits using cache= probing=20 > > and jump prediction buffers. > >=20 > > Yes, you don't want to leak the information using mmap(MAP_FIXED), but = CPU will=20 > > leak it for you, anyway. >=20 > Depends on the CPU I think, and CPU vendors are busy trying to mitigate t= his=20 > angle. I believe any x86 CPU running Linux will leak it. And with CPU vendors putting "artifical inteligence" into branch prediction, no, I don't think it is going to get better. That does not mean we shoudl not prevent mmap() info leak, but... Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlnXXWUACgkQMOfwapXb+vLHdQCfT0gtt1DcnPzO7HUoTmQNbTIP 73cAn2DmS20EcLXQtKA4VV7Dur1vaFqH =9iUT -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- --===============4848466927645144709== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4848466927645144709==--