From: Ard Biesheuvel <[email protected]> Date: Thu, 8 Jan 2026 09:25:27 +0000
> This series is a follow-up to a series I sent a bit more than a year > ago, to switch to PIE linking of x86_64 vmlinux, which is a prerequisite > for further hardening measures, such as fg-kaslr [1], as well as further > harmonization of the boot protocols between architectures [2]. > > The main sticking point is the fact that PIE linking on x86_64 requires > PIE codegen, and that was shot down before on the basis that > a) GOTs in fully linked binaries are stupid > b) the code size increase would be prohibitive > c) the performance would suffer. > > This series implements PIE codegen without permitting the use of GOT > slots. The code size increase is between 0.2% (clang) and 0.5% (gcc), > and I could not identify any performance regressions (using hackbench) > on various different micro-architectures that I tried it on. > (Suggestions for other benchmarks/test cases are welcome) > > So now that we have some actual numbers, I would like to try and revisit > this discussion, and get a conclusion on whether this is really a > non-starter. Note that only the KASLR kernel would rely on this, and > disabling CONFIG_RANDOMIZE_BASE will revert to the current situation > (provided that patch #4 is applied) > > Some minor asm tweaks are needed too (patches #9 - #17), but those all > seem uncontroversial to me. > > The first 5 patches are general cleanup, and could be taken into > consideration independently of the discussion around PIC codegen. > > [1] There have been a few attempts at landing fine grained KASLR for > x86, but the main problem is that it was tied to the x86 relocation > format, which deviates from how fully linked relocatable ELF binaries > are generally constructed (using PIE). Implementing fgkaslr in the ELF > domain would make it suitable for other architectures too, as well as > other use cases (bare metal or hosted) where no dynamic linking is > performed (firmware, hypervisors). In order to implement this properly, > i.e., with debugging support etc, it needs support from the tooling > side. (Fine grained KASLR in combination with execute-only code mappings > makes it extremely difficult for an attacker to subvert the control flow > in the kernel in a way that can be meaningfully exploited). In case anybody is interested... The latest (to my knowledge) experiments with FG-KALSR was my side project reviving Kristen's old series (and then rewriting it completely): [0] I haven't worked on it since then, as I work in an XDP/netmem/whatever team, i.e. networking, not x86, and free time for side projects shrunk severely since 2022. Maybe someone would pick it up again some day, just like I picked up Kristen's series back then... [0] https://github.com/alobakin/linux/commits/fgkaslr Thanks, Olek
