[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization
- To: "H. Peter Anvin" <hpa@xxxxxxxxx>
- From: Ingo Molnar <mingo@xxxxxxxxxx>
- Date: Sat, 23 Sep 2017 12:00:29 +0200
- Cc: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, kvm list <kvm@xxxxxxxxxxxxxxx>, Radim Krčmář <rkrcmar@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>, Christopher Li <sparse@xxxxxxxxxxx>, Alexei Starovoitov <ast@xxxxxxxxxx>, David Howells <dhowells@xxxxxxxxxx>, Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>, Pavel Machek <pavel@xxxxxx>, Kernel Hardening <kernel-hardening@xxxxxxxxxxxxxxxxxx>, Christoph Lameter <cl@xxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, Daniel Borkmann <daniel@xxxxxxxxxxxxx>, Matthew Wilcox <mawilcox@xxxxxxxxxxxxx>, Peter Foley <pefoley2@xxxxxxxxxxx>, Joerg Roedel <joro@xxxxxxxxxx>, "Rafael J . Wysocki" <rafael.j.wysocki@xxxxxxxxx>, Daniel Micay <danielmicay@xxxxxxxxx>, Baoquan He <bhe@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-sparse@xxxxxxxxxxxxxxx, Matthias Kaehlcke <mka@xxxxxxxxxxxx>, linux-arch <linux-arch@xxxxxxxxxxxxxxx>, Waiman Long <longman@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxx>, Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx>, Len Brown <len.brown@xxxxxxxxx>, Rik van Riel <riel@xxxxxxxxxx>, Chris Metcalf <cmetcalf@xxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Linux PM list <linux-pm@xxxxxxxxxxxxxxx>, Brian Gerst <brgerst@xxxxxxxxx>, "H . J . Lu" <hjl.tools@xxxxxxxxx>, Steven Rostedt <rostedt@xxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Josh Poimboeuf <jpoimboe@xxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Dou Liyang <douly.fnst@xxxxxxxxxxxxxx>, Paul Bolle <pebolle@xxxxxxxxxx>, "Paul E . McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>, "Rafael J . Wysocki" <rjw@xxxxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, "David S . Miller" <davem@xxxxxxxxxxxxx>, Kyle Huey <me@xxxxxxxxxxxx>, Lukas Wunner <lukas@xxxxxxxxx>, linux-crypto@xxxxxxxxxxxxxxx, Rob Landley <rob@xxxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Tom Lendacky <thomas.lendacky@xxxxxxx>, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Thomas Garnier <thgarnie@xxxxxxxxxx>, "Kirill A . Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
- Delivery-date: Sat, 23 Sep 2017 10:00:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
* H. Peter Anvin <hpa@xxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|