[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 11:49:59 +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>, 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 <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Sparse Mailing-list <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 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>, Thomas Garnier <thgarnie@xxxxxxxxxx>, "Kirill A . Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
- Delivery-date: Sat, 23 Sep 2017 09:50:14 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
* H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 09/22/17 09:32, Ingo Molnar wrote:
> >
> > BTW., I think things improved with ORC because with ORC we have RBP as an
> > extra
> > register and with PIE we lose RBX - so register pressure in code generation
> > is
> > lower.
> >
>
> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64
> has RIP-relative addressing there is no need for a dedicated PIC register.
Indeed, but we'd use a new register _a lot_ for constructs, transforming:
mov r9,QWORD PTR [r11*8-0x7e3da060] (8 bytes)
into:
lea rbx,[rip+<off>] (7 bytes)
mov r9,QWORD PTR [rbx+r11*8] (6 bytes)
... which I suppose is quite close to (but not the same as) 'losing' RBX.
Of course the compiler can pick other registers as well, not that it matters
much
to register pressure in larger functions in the end. Plus if the compiler has
to
pick a callee-saved register there's the additional saving/restoring overhead
of
that as well.
Right?
> I'm somewhat confused how we can have as much as almost 1% overhead. I
> suspect
> that we end up making a GOT and maybe even a PLT for no good reason.
So the above transformation alone would explain a good chunk of the overhead I
think.
Thanks,
Ingo
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|