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:06:48 +0100
From:   Uros Bizjak <ubizjak@...il.com>
To:     David Laight <David.Laight@...lab.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

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

and in [1]:

"Ack.  We did this for 32-bit and got few complaints. Let’s finish the job."

Uros.

Powered by blists - more mailing lists