RE: [PATCH v5 00/16] x86-64: Stack protector and percpu improvements

David Laight posted 16 patches 1 week, 6 days ago
Only 0 patches received!
RE: [PATCH v5 00/16] x86-64: Stack protector and percpu improvements
Posted by David Laight 1 week, 6 days ago
From: Brian Gerst
> Sent: 09 November 2024 15:11
> 
> On Sat, Nov 9, 2024 at 4:31 AM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Brian Gerst
> > > Sent: 05 November 2024 15:58
> > >
> > > 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.
> > >
> > > v5:
> > > - Added two patches from Ard Biesheuvel to make stack protector work
> > >   properly when compiling with clang.
> > > - Raise minimum GCC version to 8.1 for x86.
> > > - Drop objtool conversion code.
> >
> > Is there any actual need to raise the GCC level?
> > Isn't it enough just to disable stack protection with older compilers?
> > The percpu layout can then always be the new (sane) one.
> 
> Earlier versions of this series did make stack protector support
> conditional on newer compilers.  That got rejected.  I then added
> objtool support to convert the code old compilers produced.  That also
> got rejected.  I guess I can't please everyone.

I certainly wouldn't have bothered hacking objtool.

> > Is there even a selectable CONFIG_STACK_PROTECTOR?
> > Can than depend on gcc >= 8.1 for x86-64?
> 
> Yes, stack protector support is optional, but practically all distro
> kernels enable it.

They include all sorts of stuff that slows things down :-)
But I'd rather be able to build and test kernels than have the stack protector.

> > I've a slight vested interest in that the system I test kernels on
> > has gcc 7.5.0 installed :-)
> 
> What distro is on that system?  Is it still actively supported?

The system in running Ubuntu 18.04 LTS - and still receives updates.
I do run locally build kernels on it, but I could just be building kernels.
Seems a shame to force an update for something I can just deselect.

For reference RHEL7 is still supported but has a 4.8.5 compiler.
So it is a long time since that has self-hosted kernels.
We build software for release on Centos-7 as an easy way to get an old glibc (etc),
although buildroot/busybox (x86-64) 'distribution' has to use a newer
compiler - the grub build fails well before you get to a kernel!

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)