Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu_0o+PrMAWRSP5Y4R7QO87+zAYf=B=VDF1icqJvWL0PoA@mail.gmail.com>
Date: Wed, 19 Jul 2017 23:58:07 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Thomas Garnier <thgarnie@...gle.com>, Brian Gerst <brgerst@...il.com>, 
	Herbert Xu <herbert@...dor.apana.org.au>, "David S . Miller" <davem@...emloft.net>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...hat.com>, 
	Arnd Bergmann <arnd@...db.de>, Matthias Kaehlcke <mka@...omium.org>, 
	Boris Ostrovsky <boris.ostrovsky@...cle.com>, Juergen Gross <jgross@...e.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>, 
	Joerg Roedel <joro@...tes.org>, Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>, 
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Borislav Petkov <bp@...e.de>, 
	Christian Borntraeger <borntraeger@...ibm.com>, "Rafael J . Wysocki" <rjw@...ysocki.net>, 
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Tejun Heo <tj@...nel.org>, 
	Christoph Lameter <cl@...ux.com>, Kees Cook <keescook@...omium.org>, 
	Paul Gortmaker <paul.gortmaker@...driver.com>, Chris Metcalf <cmetcalf@...lanox.com>, 
	"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Christopher Li <sparse@...isli.org>, Dou Liyang <douly.fnst@...fujitsu.com>, 
	Masahiro Yamada <yamada.masahiro@...ionext.com>, Daniel Borkmann <daniel@...earbox.net>, 
	Markus Trippelsdorf <markus@...ppelsdorf.de>, Peter Foley <pefoley2@...oley.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Tim Chen <tim.c.chen@...ux.intel.com>, 
	Catalin Marinas <catalin.marinas@....com>, Matthew Wilcox <mawilcox@...rosoft.com>, 
	Michal Hocko <mhocko@...e.com>, Rob Landley <rob@...dley.net>, Jiri Kosina <jkosina@...e.cz>, 
	"H . J . Lu" <hjl.tools@...il.com>, Paul Bolle <pebolle@...cali.nl>, Baoquan He <bhe@...hat.com>, 
	Daniel Micay <danielmicay@...il.com>, "the arch/x86 maintainers" <x86@...nel.org>, 
	"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, xen-devel@...ts.xenproject.org, 
	kvm list <kvm@...r.kernel.org>, linux-pm <linux-pm@...r.kernel.org>, 
	linux-arch <linux-arch@...r.kernel.org>, Linux-Sparse <linux-sparse@...r.kernel.org>, 
	Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [RFC 06/22] kvm: Adapt assembly for PIE support

On 19 July 2017 at 23:27, H. Peter Anvin <hpa@...or.com> wrote:
> On 07/19/17 08:40, Thomas Garnier wrote:
>>>
>>> This doesn't look right.  It's accessing a per-cpu variable.  The
>>> per-cpu section is an absolute, zero-based section and not subject to
>>> relocation.
>>
>> PIE does not respect the zero-based section, it tries to have
>> everything relative. Patch 16/22 also adapt per-cpu to work with PIE
>> (while keeping the zero absolute design by default).
>>
>
> This is silly.  The right thing is for PIE is to be explicitly absolute,
> without (%rip).  The use of (%rip) memory references for percpu is just
> an optimization.
>

Sadly, there is an issue in binutils that may prevent us from doing
this as cleanly as we would want.

For historical reasons, bfd.ld emits special symbols like
__GLOBAL_OFFSET_TABLE__ as absolute symbols with a section index of
SHN_ABS, even though it is quite obvious that they are relative like
any other symbol that points into the image. Unfortunately, this means
that binutils needs to emit R_X86_64_RELATIVE relocations even for
SHN_ABS symbols, which means we lose the ability to use both absolute
and relocatable symbols in the same PIE image (unless the reloc tool
can filter them out)

More info here:
https://sourceware.org/bugzilla/show_bug.cgi?id=19818

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.