[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: Thomas Garnier <thgarnie@xxxxxxxxxx>
- From: Ingo Molnar <mingo@xxxxxxxxxx>
- Date: Thu, 17 Aug 2017 10:09:20 +0200
- Cc: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, 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>, "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>, 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>, Kyle Huey <me@xxxxxxxxxxxx>, Lukas Wunner <lukas@xxxxxxxxx>, Linux Crypto Mailing List <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>, "David S . Miller" <davem@xxxxxxxxxxxxx>, "Kirill A . Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
- Delivery-date: Thu, 17 Aug 2017 08:09:38 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
* Thomas Garnier <thgarnie@xxxxxxxxxx> wrote:
> > > -model=small/medium assume you are on the low 32-bit. It generates
> > > instructions where the virtual addresses have the high 32-bit to be zero.
> >
> > How are these assumptions hardcoded by GCC? Most of the instructions should
> > be
> > relocatable straight away, as most call/jump/branch instructions are
> > RIP-relative.
>
> I think PIE is capable to use relative instructions well. mcmodel=large
> assumes
> symbols can be anywhere.
So if the numbers in your changelog and Kconfig text cannot be trusted, there's
this description of the size impact which I suspect is less susceptible to
measurement error:
+ The kernel and modules will generate slightly more assembly (1 to 2%
+ increase on the .text sections). The vmlinux binary will be
+ significantly smaller due to less relocations.
... but describing a 1-2% kernel text size increase as "slightly more assembly"
shows a gratituous disregard to kernel code generation quality! In reality
that's
a huge size increase that in most cases will almost directly transfer to a 1-2%
slowdown for kernel intense workloads.
Where does that size increase come from, if PIE is capable of using relative
instructins well? Does it come from the loss of a generic register and the
resulting increase in register pressure, stack spills, etc.?
So I'm still unhappy about this all, and about the attitude surrounding it.
Thanks,
Ingo
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|