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:   Sun, 14 Nov 2021 13:29:46 -0500
From:   Brian Gerst <brgerst@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        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 Sun, Nov 14, 2021 at 6:03 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> 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@...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.
>
> 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?

The best reason is that the percpu section is currently not subject to
KASLR.  It actually needs extra support to counter the effects of
relocation.  There have also been a number of linker bugs over the
years that have had to be worked around.

If we were to decide to drop the fixed stack protector the diffstat
would look something like:

 arch/x86/Makefile                         |  19 ++--
 arch/x86/boot/compressed/misc.c           |  12 ---
 arch/x86/entry/entry_64.S                 |   2 +-
 arch/x86/include/asm/percpu.h             |  22 -----
 arch/x86/include/asm/processor.h          |  24 ++---
 arch/x86/include/asm/stackprotector.h     |  13 +--
 arch/x86/kernel/asm-offsets_64.c          |   6 --
 arch/x86/kernel/cpu/common.c              |   8 +-
 arch/x86/kernel/head_64.S                 |  11 ++-
 arch/x86/kernel/irq_64.c                  |   1 -
 arch/x86/kernel/vmlinux.lds.S             |  33 -------
 arch/x86/tools/relocs.c                   | 143 +-----------------------------
 arch/x86/xen/xen-head.S                   |  10 +--
 scripts/gcc-x86_64-has-stack-protector.sh |   2 +-
 14 files changed, 35 insertions(+), 271 deletions(-)

--
Brian Gerst