linux-kernel - Re: [PATCH v4 00/16] 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]

Message-ID: <CAMzpN2go9mmyWRb9vsg7O1aAtSKrW=HqcZYmddkq7eZQQHuM1Q@mail.gmail.com>
Date: Sun, 24 Mar 2024 01:43:55 -0400
From: Brian Gerst <brgerst@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Uros Bizjak <ubizjak@...il.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>, 
	David.Laight@...lab.com, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v4 00/16] x86-64: Stack protector and percpu improvements

On Sun, Mar 24, 2024 at 12:05 AM Ingo Molnar <mingo@...nel.org> wrote:
>
>
> * Brian Gerst <brgerst@...il.com> wrote:
>
> > On Sat, Mar 23, 2024 at 10:25 PM Ingo Molnar <mingo@...nel.org> wrote:
> > >
> > >
> > > * Uros Bizjak <ubizjak@...il.com> wrote:
> > >
> > > > On Fri, Mar 22, 2024 at 5:52 PM Brian Gerst <brgerst@...il.com> wrote:
> > > > >
> > > > > 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 other architectures.  In turn, this allows removal of code that was
> > > > > needed to support the zero-based percpu section.
> > > >
> > > > The number of simplifications throughout the code, enabled by this
> > > > patch set, is really impressive, and it reflects the number of
> > > > workarounds to enable the feature that was originally not designed for
> > > > the kernel usage. As noted above, this issue was recognized in the GCC
> > > > compiler and the stack protector support was generalized by adding
> > > > configurable location for the stack protector value [1,2].
> > > >
> > > > The improved stack protector support was implemented in gcc-8.1,
> > > > released on May 2, 2018, when linux 4.17 was in development. In light
> > > > of this fact, and 5 (soon 6) GCC major releases later, I'd like to ask
> > > > if the objtool support to fixup earlier compilers is really necessary.
> > > > Please note that years ago x86_32 simply dropped stack protector
> > > > support with earlier compilers and IMO, we should follow this example
> > > > also with x86_64, because:
> > >
> > > Ack on raising the minimum version requirement for x86-64
> > > stackprotector to 8.1 or so - this causes no real pain on the distro
> > > side: when *this* new kernel of ours is picked by a distro, it almost
> > > always goes hand in hand with a compiler version upgrade.
> > >
> > > We should be careful with fixes marked for -stable backport, but other
> > > than that, new improvements like Brian's series are a fair game to
> > > tweak compiler version requirements.
> > >
> > > But please emit a (single) prominent build-time warning if a feature is
> > > disabled though, even if there are no functional side-effects, such as
> > > for hardening features.
> >
> > Disabled for any reason or only if the compiler lacks support?
>
> Only if the user desires to have it enabled, but it's not possible due
> to compiler (or other build environment) reasons. Ie. if something
> unexpected happens from the user's perspective.
>
> The .config option is preserved even if the compiler doesn't support
> it, right?
>
> I suspect this should also cover features that get select-ed by a
> feature that the user enables. (Not sure about architecture level
> select-ed options.)
>
> Thanks,
>
>         Ingo

I could add something like:

comment "Stack protector is not supported by the architecture or compiler"
       depends on !HAVE_STACKPROTECTOR

But, "make oldconfig" will still silently disable stack protector if
the compiler doesn't support the new options.  It does put the comment
into the .config file though, so that may be enough.

Brian Gerst