From: Peter Zijlstra <peterz@infradead.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: Andy Lutomirski <luto@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 3/3] x86_64: Use relative per-cpu offsets
Date: Sun, 14 Nov 2021 12:03:05 +0100 [thread overview]
Message-ID: <20211114110305.GN174703@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAMzpN2gbOzsmnAh330+zk+ZZQmk-xNdUdCar6WaPrvHtgzknTA@mail.gmail.com>
On Sat, Nov 13, 2021 at 11:54:19PM -0500, Brian Gerst wrote:
> On Sat, Nov 13, 2021 at 8:18 PM Andy Lutomirski <luto@kernel.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.
Can someone spell out these benefits please? To me having per-cpu start
at 0 makes perfect sense, how does not having that make things better?
next prev parent reply other threads:[~2021-11-14 11:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-13 12:40 [PATCH 0/3] x86-64: Stack protector and percpu improvements Brian Gerst
2021-11-13 12:40 ` [PATCH 1/3] x86-64: Use per-cpu stack canary if supported by compiler Brian Gerst
2021-11-13 12:40 ` [PATCH 2/3] x86/relocs: Make absolute percpu relocations conditional Brian Gerst
2021-11-13 12:40 ` [PATCH 3/3] x86_64: Use relative per-cpu offsets Brian Gerst
2021-11-14 1:18 ` Andy Lutomirski
2021-11-14 4:24 ` H. Peter Anvin
2021-11-14 4:54 ` Brian Gerst
2021-11-14 11:03 ` Peter Zijlstra [this message]
2021-11-14 18:29 ` Brian Gerst
2021-11-15 18:12 ` Andy Lutomirski
2021-11-15 20:44 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211114110305.GN174703@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.