[PATCH v2 00/11] x86-64: Stack protector and percpu improvements

Brian Gerst posted 11 patches 2 years, 1 month ago
There is a newer version of this series
arch/x86/Kconfig                          |   7 +-
arch/x86/Makefile                         |  19 +--
arch/x86/boot/compressed/misc.c           |  14 +--
arch/x86/entry/entry_64.S                 |   2 +-
arch/x86/include/asm/percpu.h             |  22 ----
arch/x86/include/asm/processor.h          |  28 +----
arch/x86/include/asm/stackprotector.h     |  37 ++----
arch/x86/kernel/Makefile                  |   2 +
arch/x86/kernel/asm-offsets_64.c          |   6 -
arch/x86/kernel/cpu/common.c              |   8 +-
arch/x86/kernel/head_64.S                 |  10 +-
arch/x86/kernel/irq_64.c                  |   1 -
arch/x86/kernel/setup_percpu.c            |  12 +-
arch/x86/kernel/vmlinux.lds.S             |  35 ------
arch/x86/platform/pvh/head.S              |   4 +-
arch/x86/tools/relocs.c                   | 136 +---------------------
arch/x86/xen/xen-head.S                   |   6 +-
include/asm-generic/vmlinux.lds.h         |   1 -
include/linux/percpu-defs.h               |  12 --
init/Kconfig                              |  11 +-
kernel/kallsyms.c                         |  12 +-
scripts/gcc-x86_32-has-stack-protector.sh |   8 --
scripts/gcc-x86_64-has-stack-protector.sh |   4 -
scripts/kallsyms.c                        |  80 +++----------
scripts/link-vmlinux.sh                   |   4 -
25 files changed, 61 insertions(+), 420 deletions(-)
delete mode 100755 scripts/gcc-x86_32-has-stack-protector.sh
delete mode 100755 scripts/gcc-x86_64-has-stack-protector.sh
[PATCH v2 00/11] x86-64: Stack protector and percpu improvements
Posted by Brian Gerst 2 years, 1 month ago
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.

v2:
- Include PVH boot in GSBASE changes.
- Split out removal of 64-bit test script to give full context on why
  it's not needed anymore.
- Formatting and comment cleanups.

Brian Gerst (11):
  x86/stackprotector/32: Remove stack protector test script
  x86/stackprotector/64: Remove stack protector test script
  x86/boot: Disable stack protector for early boot code
  x86/pvh: Use fixed_percpu_data for early boot GSBASE
  x86/stackprotector/64: Convert stack protector to normal percpu
    variable
  x86/percpu/64: Remove fixed_percpu_data
  x86/percpu/64: Use relative percpu offsets
  x86/boot/64: Remove inverse relocations
  x86/percpu/64: Remove INIT_PER_CPU macros
  percpu: Remove PER_CPU_FIRST_SECTION
  kallsyms: Remove KALLSYMS_ABSOLUTE_PERCPU

 arch/x86/Kconfig                          |   7 +-
 arch/x86/Makefile                         |  19 +--
 arch/x86/boot/compressed/misc.c           |  14 +--
 arch/x86/entry/entry_64.S                 |   2 +-
 arch/x86/include/asm/percpu.h             |  22 ----
 arch/x86/include/asm/processor.h          |  28 +----
 arch/x86/include/asm/stackprotector.h     |  37 ++----
 arch/x86/kernel/Makefile                  |   2 +
 arch/x86/kernel/asm-offsets_64.c          |   6 -
 arch/x86/kernel/cpu/common.c              |   8 +-
 arch/x86/kernel/head_64.S                 |  10 +-
 arch/x86/kernel/irq_64.c                  |   1 -
 arch/x86/kernel/setup_percpu.c            |  12 +-
 arch/x86/kernel/vmlinux.lds.S             |  35 ------
 arch/x86/platform/pvh/head.S              |   4 +-
 arch/x86/tools/relocs.c                   | 136 +---------------------
 arch/x86/xen/xen-head.S                   |   6 +-
 include/asm-generic/vmlinux.lds.h         |   1 -
 include/linux/percpu-defs.h               |  12 --
 init/Kconfig                              |  11 +-
 kernel/kallsyms.c                         |  12 +-
 scripts/gcc-x86_32-has-stack-protector.sh |   8 --
 scripts/gcc-x86_64-has-stack-protector.sh |   4 -
 scripts/kallsyms.c                        |  80 +++----------
 scripts/link-vmlinux.sh                   |   4 -
 25 files changed, 61 insertions(+), 420 deletions(-)
 delete mode 100755 scripts/gcc-x86_32-has-stack-protector.sh
 delete mode 100755 scripts/gcc-x86_64-has-stack-protector.sh

-- 
2.41.0
RE: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
Posted by David Laight 2 years, 1 month ago
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.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Re: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
Posted by Uros Bizjak 2 years, 1 month ago
On Sun, Oct 29, 2023 at 10:42 PM David Laight <David.Laight@aculab.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.
RE: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
Posted by David Laight 2 years, 1 month ago
From: Uros Bizjak
> Sent: 30 October 2023 08:07
> 
> On Sun, Oct 29, 2023 at 10:42 PM David Laight <David.Laight@aculab.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)
Re: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
Posted by Uros Bizjak 2 years, 1 month ago
On Mon, Oct 30, 2023 at 10:05 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Uros Bizjak
> > Sent: 30 October 2023 08:07
> >
> > On Sun, Oct 29, 2023 at 10:42 PM David Laight <David.Laight@aculab.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.

It's this part:

--cut here--
diff --git a/scripts/gcc-x86_32-has-stack-protector.sh
b/scripts/gcc-x86_32-has-stack-protector.sh
index f5c119495254..51f864d76bd6 100755
--- a/scripts/gcc-x86_32-has-stack-protector.sh
+++ b/scripts/gcc-x86_32-has-stack-protector.sh
@@ -1,4 +1,8 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0

-echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32
-O0 -fstack-protector - -o - 2> /dev/null | grep -q "%gs"
+# This requires GCC 8.1 or better.  Specifically, we require
+# -mstack-protector-guard-reg, added by
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
+
+echo "int foo(void) { char X[200]; return 3; }" | $* -S -x c -c -m32
-O0 -fstack-protector -mstack-protector-guard-reg=fs
-mstack-protector-guard-symbol=stack_canary - -o - 2> /dev/null | grep
-q "%fs"
--cut here--

Uros.
Re: [PATCH v2 00/11] x86-64: Stack protector and percpu improvements
Posted by Brian Gerst 2 years, 1 month ago
On Sun, Oct 29, 2023 at 5:42 PM David Laight <David.Laight@aculab.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.

What distribution are you using that still relies on that old of a compiler?

Brian Gerst