[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25a2974a-fbb4-ea4b-d090-582d6d0de7fd@zytor.com>
Date: Wed, 19 Jul 2017 16:33:17 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Thomas Garnier <thgarnie@...gle.com>, Brian Gerst <brgerst@...il.com>
Cc: 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>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
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@...r.kernel.org,
Kernel Hardening <kernel-hardening@...ts.openwall.com>
Subject: Re: [RFC 16/22] x86/percpu: Adapt percpu for PIE support
On 07/19/17 11:26, Thomas Garnier wrote:
> On Tue, Jul 18, 2017 at 8:08 PM, Brian Gerst <brgerst@...il.com> wrote:
>> On Tue, Jul 18, 2017 at 6:33 PM, Thomas Garnier <thgarnie@...gle.com> wrote:
>>> Perpcu uses a clever design where the .percu ELF section has a virtual
>>> address of zero and the relocation code avoid relocating specific
>>> symbols. It makes the code simple and easily adaptable with or without
>>> SMP support.
>>>
>>> This design is incompatible with PIE because generated code always try to
>>> access the zero virtual address relative to the default mapping address.
>>> It becomes impossible when KASLR is configured to go below -2G. This
>>> patch solves this problem by removing the zero mapping and adapting the GS
>>> base to be relative to the expected address. These changes are done only
>>> when PIE is enabled. The original implementation is kept as-is
>>> by default.
>>
>> The reason the per-cpu section is zero-based on x86-64 is to
>> workaround GCC hardcoding the stack protector canary at %gs:40. So
>> this patch is incompatible with CONFIG_STACK_PROTECTOR.
>
> Ok, that make sense. I don't want this feature to not work with
> CONFIG_CC_STACKPROTECTOR*. One way to fix that would be adding a GDT
> entry for gs so gs:40 points to the correct memory address and
> gs:[rip+XX] works correctly through the MSR.
What are you talking about? A GDT entry and the MSR do the same thing,
except that a GDT entry is limited to an offset of 0-0xffffffff (which
doesn't work for us, obviously.)
> Given the separate
> discussion on mcmodel, I am going first to check if we can move from
> PIE to PIC with a mcmodel=small or medium that would remove the percpu
> change requirement. I tried before without success but I understand
> better percpu and other components so maybe I can make it work.
>> 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.
>
> I agree that it is odd but that's how the compiler generates code. I
> will re-explore PIC options with mcmodel=small or medium, as mentioned
> on other threads.
Why should the way compiler generates code affect the way we do things
in assembly?
That being said, the compiler now has support for generating this kind
of code explicitly via the __seg_gs pointer modifier. That should let
us drop the __percpu_prefix and just use variables directly. I suspect
we want to declare percpu variables as "volatile __seg_gs" to account
for the possibility of CPU switches.
Older compilers won't be able to work with this, of course, but I think
that it is acceptable for those older compilers to not be able to
support PIE.
-hpa
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.
