Date: Sun, 24 Mar 2024 11:53:05 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Brian Gerst <brgerst@...il.com>
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


* Brian Gerst <brgerst@...il.com> wrote:

> 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.

So I was thinking more along the lines of emitting an actual warning to 
the build log, every time the compiler check is executed and fails to 
detect [certain] essential or good-to-have compiler features.

A bit like the red '[ OFF ]' build lines during the perf build:

Auto-detecting system features:

..                                   dwarf: [ on  ]
..                      dwarf_getlocations: [ on  ]
..                                   glibc: [ on  ]
..                                  libbfd: [ on  ]
..                          libbfd-buildid: [ on  ]
..                                  libcap: [ on  ]
..                                  libelf: [ on  ]
..                                 libnuma: [ on  ]
..                  numa_num_possible_cpus: [ on  ]
..                                 libperl: [ on  ]
..                               libpython: [ on  ]
..                               libcrypto: [ on  ]
..                               libunwind: [ on  ]
..                      libdw-dwarf-unwind: [ on  ]
..                             libcapstone: [ OFF ]  <========
..                                    zlib: [ on  ]
..                                    lzma: [ on  ]
..                               get_cpuid: [ on  ]
..                                     bpf: [ on  ]
..                                  libaio: [ on  ]
..                                 libzstd: [ on  ]

.. or something like that.

Thanks,

	Ingo

Powered by blists - more mailing lists