[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: Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>
- From: "H. Peter Anvin" <hpa@xxxxxxxxx>
- Date: Fri, 22 Sep 2017 11:27:07 -0700
- Cc: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Len Brown <len.brown@xxxxxxxxx>, Radim Krčmář <rkrcmar@xxxxxxxxxx>, 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>, 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>, Tom Lendacky <thomas.lendacky@xxxxxxx>, 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>, Baoquan He <bhe@xxxxxxxxxx>, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, kvm list <kvm@xxxxxxxxxxxxxxx>, 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>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Thomas Garnier <thgarnie@xxxxxxxxxx>, "Kirill A . Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
- Delivery-date: Fri, 22 Sep 2017 18:51:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 08/21/17 07:28, Peter Zijlstra wrote:
>
> Ah, I see, this is large mode and that needs to use MOVABS to load 64bit
> immediates. Still, small RIP relative should be able to live at any
> point as long as everything lives inside the same 2G relative range, so
> would still allow the goal of increasing the KASLR range.
>
> So I'm not seeing how we need large mode for that. That said, after
> reading up on all this, RIP relative will not be too pretty either,
> while CALL is naturally RIP relative, data still needs an explicit %rip
> offset, still loads better than the large model.
>
The large model makes no sense whatsoever. I think what we're actually
looking for is the small-PIC model.
Ingo asked:
> I.e. is there no GCC code generation mode where code can be placed anywhere
> in the
> canonical address space, yet call and jump distance is within 31 bits so that
> the
> generated code is fast?
That's the small-PIC model. I think if all symbols are forced to hidden
then it won't even need a GOT/PLT.
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.
-hpa
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|