From: Pavel Machek Subject: Re: x86: PIE support and option to extend KASLR randomization Date: Mon, 25 Sep 2017 00:37:08 +0200 Message-ID: <20170924223708.GA12616@amd> References: <20170810172615.51965-1-thgarnie@google.com> <20170811124127.kkb5pnkljz4umxuj@gmail.com> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Cc: "H. Peter Anvin" , Peter Zijlstra , Thomas Garnier , Herbert Xu , "David S . Miller" , Thomas Gleixner , Ingo Molnar , Josh Poimboeuf , Arnd Bergmann , Matthias Kaehlcke , Boris Ostrovsky , Juergen Gross , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Joerg Roedel , Tom Lendacky , Andy Lutomirski , Borislav Petkov , Brian Gerst , "Kirill A . Shutemov" , "Rafael J . Wysocki" , Len Brown , Tejun Heo , Christo To: Ingo Molnar Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: <20170923100029.6nzpui6c3ke76bbs@gmail.com> List-Id: linux-crypto.vger.kernel.org --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > We do need to consider how we want modules to fit into whatever model we > > choose, though. They can be adjacent, or we could go with a more > > traditional dynamic link model where the modules can be separate, and > > chained together with the main kernel via the GOT. >=20 > So I believe we should start with 'adjacent'. The thing is, having module= s=20 > separately randomized mostly helps if any of the secret locations fails a= nd > we want to prevent hopping from one to the other. But if one the kernel-p= rivileged > secret location fails then KASLR has already failed to a significant degr= ee... >=20 > So I think the large-PIC model for modules does not buy us any real advan= tages in=20 > practice, and the disadvantages of large-PIC are real and most Linux user= s have to=20 > pay that cost unconditionally, as distro kernels have half of their kerne= l=20 > functionality living in modules. >=20 > But I do see fundamental value in being able to hide the kernel somewhere= in a ~48=20 > bits address space, especially if we also implement Linus's suggestion to= utilize=20 > the lower bits as well. 0..281474976710656 is a nicely large range and wi= ll get=20 > larger with time. >=20 > But it should all be done smartly and carefully: >=20 > For example, there would be collision with regular user-space mappings, r= ight? > Can local unprivileged users use mmap(MAP_FIXED) probing to figure out wh= ere > the kernel lives? Local unpriviledged users can probably get your secret bits using cache probing and jump prediction buffers. Yes, you don't want to leak the information using mmap(MAP_FIXED), but CPU will leak it for you, anyway. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlnIM5QACgkQMOfwapXb+vJIOwCdHR6N9F/ftl4zHYKwJHnThgDz BhEAn2Rqlf4Dn3hmUmy6pDrdlrDma6Ry =oY77 -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62--