[RFC 0/3] kbuild: modules: Fixup arm64 BTI relocations

The kernel module loader, the arm64 ABI, GCC/Clang, and the static
linkers operate with slightly different assumptions about which
functions require BTI landing pads.

A static function called only directly does not normally need a BTI
landing pad, so compilers omit it. A static linker producing an ET_REL
module treats R_AARCH64_CALL26 as a direct branch and leaves the
relocation for the module loader or later link pass. It does not know
the final distance between sections or whether the loader will later
require an indirect branch fixup.

This matters when a caller and callee are placed in different sections,
for example by __init. The arm64 module loader may replace such a
CALL26 relocation with a fixup containing an indirect branch, making an
otherwise direct only function a BTI target. Ftrace makes this more
likely because its entry NOP can replace a PAC instruction that would
otherwise be a valid BTI landing pad.

A linker could conservatively add veneers to affected cross section
calls, but that would require knowledge of arm64 module loader fixup
semantics and is not part of the generic relocatable link contract.

Lets fix this by handling the module specific transformation during
the kernel build. Scan cross section calls and, when the target lacks
a BTI compatible landing pad, place a veneer in the target section,
redirect the relocation to the veneer, and branch directly from the
veneer to the original function entry.

Jeremy Linton (3):
  kbuild: modules: Add arm64 BTI fixup utility
  kbuild: modules: Build and trigger BTI scanner for arm64
  arm64: bti: Drop compiler specific BTI checks

 arch/arm64/Kconfig         |   6 -
 scripts/Makefile           |   3 +
 scripts/Makefile.modfinal  |  12 +-
 scripts/module-bti-check.c | 665 +++++++++++++++++++++++++++++++++++++
 4 files changed, 679 insertions(+), 7 deletions(-)
 create mode 100644 scripts/module-bti-check.c

-- 
2.55.0