[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1eb4f2c46e1642519a40924ed3fe3ccc@AcuMS.aculab.com>
Date: Mon, 30 Oct 2023 09:05:48 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Uros Bizjak' <ubizjak@...il.com>
CC: Brian Gerst <brgerst@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"Ingo Molnar" <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Borislav Petkov" <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: RE: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
From: Uros Bizjak
> Sent: 30 October 2023 08:07
>
> On Sun, Oct 29, 2023 at 10:42 PM David Laight <David.Laight@...lab.com> wrote:
> >
> > From: Brian Gerst
> > > Sent: 26 October 2023 17:01
> > >
> > > 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 most other architectures. In turn, this allows removal
> > > 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.com/
>
> 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 >= 8.1
Without that anyone who already has it enabled and is using an
older compiler will get very broken kernels.
David
>
> and in [1]:
>
> "Ack. We did this for 32-bit and got few complaints. Let’s finish the job."
>
> Uros.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists