From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 25 Sep 2017 00:37:08 +0200 From: Pavel Machek 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" Content-Disposition: inline In-Reply-To: <20170923100029.6nzpui6c3ke76bbs@gmail.com> Subject: [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization To: Ingo Molnar 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 , Christoph Lameter , Paul Gortmaker , Chris Metcalf , Andrew Morton , "Paul E . McKenney" , Nicolas Pitre , Christopher Li , "Rafael J . Wysocki" , Lukas Wunner , Mika Westerberg , Dou Liyang , Daniel Borkmann , Alexei Starovoitov , Masahiro Yamada , Markus Trippelsdorf , Steven Rostedt , Kees Cook , Rik van Riel , David Howells , Waiman Long , Kyle Huey , Peter Foley , Tim Chen , Catalin Marinas , Ard Biesheuvel , Michal Hocko , Matthew Wilcox , "H . J . Lu" , Paul Bolle , Rob Landley , Baoquan He , Daniel Micay , the arch/x86 maintainers , linux-crypto@vger.kernel.org, LKML , xen-devel@lists.xenproject.org, kvm list , Linux PM list , linux-arch , linux-sparse@vger.kernel.org, Kernel Hardening , Linus Torvalds , Borislav Petkov List-ID: --+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-- 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: 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" Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Content-Disposition: inline In-Reply-To: <20170923100029.6nzpui6c3ke76bbs@gmail.com> To: Ingo Molnar 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 List-Id: linux-arch.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--