Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <20231026160100.195099-1-brgerst@gmail.com> <a094c7da294a4827994af72249262593@AcuMS.aculab.com>
 <CAFULd4ZBGzceGbRaVLuMJ+qkoUpMv-rdBZB_D=Mni5RAWzgQBQ@mail.gmail.com> <1eb4f2c46e1642519a40924ed3fe3ccc@AcuMS.aculab.com>
In-Reply-To: <1eb4f2c46e1642519a40924ed3fe3ccc@AcuMS.aculab.com>
From:   Uros Bizjak <ubizjak@gmail.com>
Date:   Mon, 30 Oct 2023 10:10:05 +0100
Message-ID: <CAFULd4Y_yt6onQn0_zQbiK=LCu25=jiFkCaPYQuvmjzTo+LZ1w@mail.gmail.com>
Subject: Re: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
To:     David Laight <David.Laight@aculab.com>
Cc:     Brian Gerst <brgerst@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>, Ingo Molnar <mingo@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Borislav Petkov <bp@alien8.de>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Oct 30, 2023 at 10:05=E2=80=AFAM David Laight <David.Laight@aculab.=
com> wrote:
>
> From: Uros Bizjak
> > Sent: 30 October 2023 08:07
> >
> > On Sun, Oct 29, 2023 at 10:42=E2=80=AFPM David Laight <David.Laight@acu=
lab.com> wrote:
> > >
> > > From: Brian Gerst
> > > > Sent: 26 October 2023 17:01
> > > >
> > > > Currently, x86-64 uses an unusual percpu layout, where the percpu s=
ection
> > > > is linked at absolute address 0.  The reason behind this is that ol=
der 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 var=
iables,
> > > > this forced the current layout.
> > > >
> > > > GCC since version 8.1 supports a configurable location for the stac=
k
> > > > 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 remo=
val
> > > > 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.co=
m/
> >
> > 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 >=3D 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=3D81708
+
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32
-O0 -fstack-protector -mstack-protector-guard-reg=3Dfs
-mstack-protector-guard-symbol=3Dstack_canary - -o - 2> /dev/null | grep
-q "%fs"
--cut here--

Uros.