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

Powered by Openwall GNU/*/Linux Powered by OpenVZ