[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMzpN2gbOzsmnAh330+zk+ZZQmk-xNdUdCar6WaPrvHtgzknTA@mail.gmail.com>
Date: Sat, 13 Nov 2021 23:54:19 -0500
From: Brian Gerst <brgerst@...il.com>
To: Andy Lutomirski <luto@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 3/3] x86_64: Use relative per-cpu offsets
On Sat, Nov 13, 2021 at 8:18 PM Andy Lutomirski <luto@...nel.org> wrote:
>
>
>
> On Sat, Nov 13, 2021, at 4:40 AM, Brian Gerst wrote:
> > The per-cpu section is currently linked at virtual address 0, because
> > older compilers hardcoded the stack protector canary value at a fixed
> > offset from the start of the GS segment. Use a standard relative offset
> > as the GS base when the stack protector is disabled, or a newer compiler
> > is used that supports a configurable location for the stack canary.
>
> Can you explain the benefit? Also, I think we should consider dropping support for the fixed model like we did on x86_32.
This patch probably makes more sense if we drop the fixed model, as
that gets rid of alot of code that works around having to link the
percpu section differently. I can respin this patchset to remove the
fixed model if it is agreed to require GCC 8.1 or later for stack
protector support. The big question is if any actively supported
distributions still use an older compiler.
--
Brian Gerst
Powered by blists - more mailing lists