linux-kernel - Re: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements

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:   Mon, 30 Oct 2023 10:10:05 +0100
From:   Uros Bizjak <ubizjak@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Brian Gerst <brgerst@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements

On Mon, Oct 30, 2023 at 10:05 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Uros Bizjak
> > Sent: 30 October 2023 08:07
> >
> > On Sun, Oct 29, 2023 at 10:42 PM David Laight <David.Laight@...lab.com> wrote:
> > >
> > > From: Brian Gerst
> > > > Sent: 26 October 2023 17:01
> > > >
> > > > Currently, x86-64 uses an unusual percpu layout, where the percpu section
> > > > is linked at absolute address 0.  The reason behind this is that older GCC
> > > > versions placed the stack protector (if enabled) at a fixed offset from the
> > > > GS segment base.  Since the GS segement is also used for percpu variables,
> > > > this forced the current layout.
> > > >
> > > > GCC since version 8.1 supports a configurable location for the stack
> > > > protector value, which allows removal of the restriction on how the percpu
> > > > section is linked.  This allows the percpu section to be linked
> > > > normally, like most other architectures.  In turn, this allows removal
> > > > of code that was needed to support the zero-based percpu section.
> > >
> > > I didn't think the minimum gcc version was anything like 8.1.
> > > I'm using 7.5.0 and I don't think that is the oldest version.
> >
> > Please see previous discussion regarding modernizing stack protector
> > on x86_64 [1]
> >
> > [1] https://lore.kernel.org/lkml/20211113124035.9180-1-brgerst@gmail.com/
> >
> > and x86_32 [2]
> >
> > [2] https://lore.kernel.org/lkml/cover.1601925251.git.luto@kernel.org/
> >
> > The conclusion in [2] is:
> >
> > "I'm all in favour of simply requiring GCC-8.1 to build a more secure
> > x86_64 kernel. Gives people an incentive to not use ancient compilers.
> >
> > And if you do want to use your ancient compiler, we'll still build, you
> > just don't get to have stackprotector."
>
> I didn't see a patch that limited 'stackprotector' to gcc >= 8.1
> Without that anyone who already has it enabled and is using an
> older compiler will get very broken kernels.

It's this part:

--cut here--
diff --git a/scripts/gcc-x86_32-has-stack-protector.sh
b/scripts/gcc-x86_32-has-stack-protector.sh
index f5c119495254..51f864d76bd6 100755
--- a/scripts/gcc-x86_32-has-stack-protector.sh
+++ b/scripts/gcc-x86_32-has-stack-protector.sh
@@ -1,4 +1,8 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0

-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32
-O0 -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+# This requires GCC 8.1 or better.  Specifically, we require
+# -mstack-protector-guard-reg, added by
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
+
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32
-O0 -fstack-protector -mstack-protector-guard-reg=fs
-mstack-protector-guard-symbol=stack_canary - -o - 2> /dev/null | grep
-q "%fs"
--cut here--

Uros.