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.

Ard Biesheuvel (2):
  x86/stackprotector: Work around strict Clang TLS symbol requirements
  x86/module: Deal with GOT based stack cookie load on Clang < 17

Brian Gerst (14):
  x86: Raise minimum GCC version to 8.1
  x86/stackprotector: Remove stack protector test scripts
  x86/boot: Disable stack protector for early boot code
  x86/pvh: Use fixed_percpu_data for early boot GSBASE
  x86/relocs: Handle R_X86_64_REX_GOTPCRELX relocations
  x86/stackprotector/64: Convert to normal percpu variable
  x86/percpu/64: Use relative percpu offsets
  x86/percpu/64: Remove fixed_percpu_data
  x86/boot/64: Remove inverse relocations
  x86/percpu/64: Remove INIT_PER_CPU macros
  percpu: Remove PER_CPU_FIRST_SECTION
  percpu: Remove PERCPU_VADDR()
  percpu: Remove __per_cpu_load
  kallsyms: Remove KALLSYMS_ABSOLUTE_PERCPU

 arch/x86/Kconfig                          |  11 +-
 arch/x86/Makefile                         |  19 +--
 arch/x86/boot/compressed/misc.c           |  14 +--
 arch/x86/entry/entry.S                    |  14 +++
 arch/x86/entry/entry_64.S                 |   2 +-
 arch/x86/include/asm/asm-prototypes.h     |   3 +
 arch/x86/include/asm/desc.h               |   1 -
 arch/x86/include/asm/elf.h                |   3 +-
 arch/x86/include/asm/percpu.h             |  22 ----
 arch/x86/include/asm/processor.h          |  28 +----
 arch/x86/include/asm/stackprotector.h     |  36 +-----
 arch/x86/kernel/Makefile                  |   2 +
 arch/x86/kernel/asm-offsets_64.c          |   6 -
 arch/x86/kernel/cpu/common.c              |  11 +-
 arch/x86/kernel/head64.c                  |   2 +-
 arch/x86/kernel/head_64.S                 |  20 ++-
 arch/x86/kernel/irq_64.c                  |   1 -
 arch/x86/kernel/module.c                  |  15 +++
 arch/x86/kernel/setup_percpu.c            |  12 +-
 arch/x86/kernel/vmlinux.lds.S             |  38 +-----
 arch/x86/platform/pvh/head.S              |  14 ++-
 arch/x86/tools/relocs.c                   | 147 ++--------------------
 arch/x86/xen/xen-head.S                   |  10 +-
 include/asm-generic/sections.h            |   2 +-
 include/asm-generic/vmlinux.lds.h         |  38 +-----
 include/linux/percpu-defs.h               |  12 --
 init/Kconfig                              |   5 -
 kernel/kallsyms.c                         |  12 +-
 mm/percpu.c                               |   4 +-
 scripts/gcc-x86_32-has-stack-protector.sh |   8 --
 scripts/gcc-x86_64-has-stack-protector.sh |   4 -
 scripts/kallsyms.c                        |  72 ++---------
 scripts/link-vmlinux.sh                   |   4 -
 scripts/min-tool-version.sh               |   2 +
 34 files changed, 122 insertions(+), 472 deletions(-)
 delete mode 100755 scripts/gcc-x86_32-has-stack-protector.sh
 delete mode 100755 scripts/gcc-x86_64-has-stack-protector.sh


base-commit: 4b9984799820b5b32b0ae1f3d8074886895a44e1
-- 
2.47.0

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.

Is there even a selectable CONFIG_STACK_PROTECTOR?
Can than depend on gcc >= 8.1 for x86-64?

I've a slight vested interest in that the system I test kernels on
has gcc 7.5.0 installed :-)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

On Sat, Nov 9, 2024 at 4:31 AM David Laight <David.Laight@aculab.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.

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

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

Brian Gerst

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