On Fri, Jan 09, 2026 at 10:21:49AM +0100, Ard Biesheuvel wrote: > On Fri, 9 Jan 2026 at 01:37, H. Peter Anvin <[email protected]> wrote: > > > > On 2026-01-08 01:25, Ard Biesheuvel wrote: > > > 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]. > > > > Kristin Accardi had fg-kasrl running without that, didn't she?
I understand "such as fg-kaslr" to have been just a terse way of saying "such as a complete multi-architectural fg-kaslr" > Yes, as a proof of concept. But it is tied to the x86 approach of > performing runtime relocations based on build time relocation data, > which is problematic now that linkers have started to perform > relaxations, as these cannot always be translated 1:1. For instance, > we already have a latent bug in the x86 relocs tool, which ignores > GOTPCREL relocations on the basis that the relocation is relative. > However, this is only true for Clang/lld, which does not update the > static relocation tables after performing relaxations. ld.bfd does > attempt to keep those tables in sync, and so a GOTPCREL relocation > should be flagged as a bug when encountered, because it means there is > a GOT slot somewhere with no relocation associated with it. Another historical bit of context is that one of the main reasons Kristen's fg-kaslr got stuck was the linker support needed for (the 65k worth of) section pass-through. That never got resolved, and the solutions either required huge linker files (that tickled performance flaws in the linkers) that resulted in 10 minute linking times, or to disable all the orphan section handling, which was a regression in our sanity checking and bug-finding. So, getting a well-behaved fg-kaslr still needs toolchain support, and getting there is going to need further design work. As far as PIE, this just makes the fg-kaslr toolchain work easier (fewer special cases), along with all the other benefits of moving to PIE. -Kees -- Kees Cook
