[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: Ingo Molnar <mingo@xxxxxxxxxx>
- From: Pavel Machek <pavel@xxxxxx>
- Date: Mon, 25 Sep 2017 00:37:08 +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>, Peter Foley <pefoley2@xxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, 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>, 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: Sun, 24 Sep 2017 22:37:52 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
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.
>
> 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?
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
