linux-kernel - RE: [PATCH v5 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] [day] [month] [year] [list]

Message-ID: <dee56ade8f2841c0b276a0b9af221981@AcuMS.aculab.com>
Date: Sat, 9 Nov 2024 21:27:06 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Brian Gerst' <brgerst@...il.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>, "H . Peter
 Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov
	<bp@...en8.de>, Ard Biesheuvel <ardb@...nel.org>, Uros Bizjak
	<ubizjak@...il.com>
Subject: RE: [PATCH v5 00/16] x86-64: Stack protector and percpu improvements

From: Brian Gerst
> Sent: 09 November 2024 15:11
> 
> On Sat, Nov 9, 2024 at 4:31 AM David Laight <David.Laight@...lab.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)