kernel-hardening - Re: x86: PIE support and option to extend KASLR randomization

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170923100029.6nzpui6c3ke76bbs@gmail.com>
Date: Sat, 23 Sep 2017 12:00:29 +0200
From: Ingo Molnar <mingo@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
	Thomas Garnier <thgarnie@...gle.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S . Miller" <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>, Arnd Bergmann <arnd@...db.de>,
	Matthias Kaehlcke <mka@...omium.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Juergen Gross <jgross@...e.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Radim Krčmář <rkrcmar@...hat.com>,
	Joerg Roedel <joro@...tes.org>,
	Tom Lendacky <thomas.lendacky@....com>,
	Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...e.de>,
	Brian Gerst <brgerst@...il.com>,
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
	"Rafael J . Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Chris Metcalf <cmetcalf@...lanox.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Christopher Li <sparse@...isli.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
	Lukas Wunner <lukas@...ner.de>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Dou Liyang <douly.fnst@...fujitsu.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Alexei Starovoitov <ast@...nel.org>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Kees Cook <keescook@...omium.org>, Rik van Riel <riel@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Waiman Long <longman@...hat.com>, Kyle Huey <me@...ehuey.com>,
	Peter Foley <pefoley2@...oley.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Michal Hocko <mhocko@...e.com>,
	Matthew Wilcox <mawilcox@...rosoft.com>,
	"H . J . Lu" <hjl.tools@...il.com>, Paul Bolle <pebolle@...cali.nl>,
	Rob Landley <rob@...dley.net>, Baoquan He <bhe@...hat.com>,
	Daniel Micay <danielmicay@...il.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	linux-crypto@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	xen-devel@...ts.xenproject.org, kvm list <kvm@...r.kernel.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	linux-sparse@...r.kernel.org,
	Kernel Hardening <kernel-hardening@...ts.openwall.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: x86: PIE support and option to extend KASLR randomization


* H. Peter Anvin <hpa@...or.com> wrote:

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

So I believe we should start with 'adjacent'. The thing is, having modules 
separately randomized mostly helps if any of the secret locations fails and
we want to prevent hopping from one to the other. But if one the kernel-privileged
secret location fails then KASLR has already failed to a significant degree...

So I think the large-PIC model for modules does not buy us any real advantages in 
practice, and the disadvantages of large-PIC are real and most Linux users have to 
pay that cost unconditionally, as distro kernels have half of their kernel 
functionality living in modules.

But I do see fundamental value in being able to hide the kernel somewhere in a ~48 
bits address space, especially if we also implement Linus's suggestion to utilize 
the lower bits as well. 0..281474976710656 is a nicely large range and will get 
larger with time.

But it should all be done smartly and carefully:

For example, there would be collision with regular user-space mappings, right?
Can local unprivileged users use mmap(MAP_FIXED) probing to figure out where
the kernel lives?

Thanks,

	Ingo
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.