linux-kernel - Re: [PATCH 3/3] x86_64: Use relative per-cpu offsets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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