Re: [PATCH 3/4] s390: Compile relocatable kernel without -fPIE

[Vasily Gorbik <gor@linux.ibm.com>]

On Tue, Feb 13, 2024 at 11:47:06AM +0100, Sumanth Korikkar wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
> 
> On s390, currently kernel uses the '-fPIE' compiler flag for compiling
> vmlinux.  This has a few problems:
> 
>   - It uses dynamic symbols (.dynsym), for which the linker refuses to
>     allow more than 64k sections.  This can break features which use
>     '-ffunction-sections' and '-fdata-sections', including kpatch-build
>     [1] and Function Granular KASLR.
> 
>   - It unnecessarily uses GOT relocations, adding an extra layer of
>     indirection for many memory accesses.
> 
> Instead of using '-fPIE', resolve all the relocations at link time and
> then manually adjust any absolute relocations (R_390_64) during boot.
> 
> This is done by first telling the linker to preserve all relocations
> during the vmlinux link.  (Note this is harmless: they are later
> stripped in the vmlinux.bin link.)
> 
> Then use the 'relocs' tool to find all absolute relocations (R_390_64)
> which apply to allocatable sections.  The offsets of those relocations
> are saved in a special section which is then used to adjust the
> relocations during boot.
> 
> (Note: For some reason, Clang occasionally creates a GOT reference, even
> without '-fPIE'.  So Clang-compiled kernels have a GOT, which needs to
> be adjusted.)
> 
> On my mostly-defconfig kernel, this reduces kernel text size by ~1.3%.
> 
> [1] https://github.com/dynup/kpatch/issues/1284
> [2] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622872.html
> [3] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625986.html
> 
> Compiler consideration:
> 
> Gcc recently implemented an optimization [2] for loading symbols without
> explicit alignment, aligning with the IBM Z ELF ABI. This ABI mandates
> symbols to reside on a 2-byte boundary, enabling the use of the larl
> instruction. However, kernel linker scripts may still generate unaligned
> symbols. To address this, a new -munaligned-symbols option has been
> introduced [3] in recent gcc versions. This option has to be used with
> future gcc versions.
> 
> Older Clang lacks support for handling unaligned symbols generated
> by kernel linker scripts when the kernel is built without -fPIE. However,
> future versions of Clang will include support for the -munaligned-symbols
> option. When the support is unavailable, compile the kernel with -fPIE
> to maintain the existing behavior.
> 
> In addition to it:
> move vmlinux.relocs to safe relocation
> 
> When the kernel is built with CONFIG_KERNEL_UNCOMPRESSED, the entire
> uncompressed vmlinux.bin is positioned in the bzImage decompressor
> image at the default kernel LMA of 0x100000, enabling it to be executed
> in-place. However, the size of .vmlinux.relocs could be large enough to
> cause an overlap with the uncompressed kernel at the address 0x100000.
> To address this issue, .vmlinux.relocs is positioned after the
> .rodata.compressed in the bzImage. Nevertheless, in this configuration,
> vmlinux.relocs will overlap with the .bss section of vmlinux.bin. To
> overcome that, move vmlinux.relocs to a safe location before clearing
> .bss and handling relocs.
> 
> [Rebased Josh Poimboeuf patches and move vmlinux.relocs
>  to safe location: Sumanth Korikkar <sumanthk@linux.ibm.com>]
> Tested-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
>  arch/s390/Kconfig                    | 15 ++++--
>  arch/s390/Makefile                   |  8 ++-
>  arch/s390/boot/.gitignore            |  1 +
>  arch/s390/boot/Makefile              | 14 ++++-
>  arch/s390/boot/boot.h                |  6 +++
>  arch/s390/boot/startup.c             | 80 +++++++++++++++++++++++++---
>  arch/s390/boot/vmlinux.lds.S         | 18 +++++++
>  arch/s390/include/asm/physmem_info.h |  1 +
>  arch/s390/kernel/vmlinux.lds.S       |  9 ++++
>  9 files changed, 139 insertions(+), 13 deletions(-)

Acked-by: Vasily Gorbik <gor@linux.ibm.com>