https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #45 from Ard Biesheuvel <ardb at kernel dot org> --- (In reply to Alexander Monakov from comment #44) > (In reply to Ard Biesheuvel from comment #43) > > arch/arm64/Makefile specifies '-shared' for the linker flags, but does not > > pass -fpic of -fpie to the compiler. We used to pass '-pie -shared' but that > > was changed a while ago to accommodate lld. > > Oof. And you couldn't drop -shared (leaving -pie) because the linker would > then write a useless .interp section? BFD ld now has -static-pie; not sure > about LLD. > I don't remember tbh. This was 7 years ago, so by now, we may be able to tidy this up a little bit. > I see that that Makefile passes -z notext, as you're trying to link a PIE > from non-PIC objects, and the linker can emit text relocations. Makes sense. > Indeed. And they are rare in AArch64 small model code anyway, and if they do appear, it is not a problem for the loader, which applies all relocations via a RW- alias of the image. > > The goal is to build a PIE (or -shared) executable, so that we get the > > dynamic relocations needed to randomize the placement of the kernel in the > > virtual address space at boot. On arm64, that doesn't currently require > > -fpic of -fpie, and adding those options results in worse code due to all > > the GOT indirections. > > (PIE with textrels, crucially, right?) > Yes. The thing PIE gives us is a RELA (or RELR) section that the startup code inside the image can access to relocate itself. There are no concerns regarding text relocations or RELRO sections etc. > > Non-PIC might be more efficient, but there are cases where we cannot use it. > > The early startup code on x86 runs from a different virtual mapping than it > > was linked at, and this has been causing lots of issues. Grep for > > RIP_REL_REF() in the Linux source tree and weep :-) > > Is x86 somehow special here, or can arm64 find itself in a similar situation? > x86 is special, because it supports sign extended 32-bit absolute immediates for its 64-bit addressing mode. This is why the 'kernel' code model exists. On older micro-architectures, MOV is more efficient than LEA, and so switching to -fstatic-pie will have more of a performance impact on x86 than on arm64. This performance impact has not been quantified, though, which is one of the things on my list. If it turns out that using PIC code on x86 (with text relocations but for 64-bit quantities only) is fast enough compared to the non-PIC kernel code model, I don't see a reason not to switch over the entire x86 kernel build. But we need it at least for a subset of objects (the ones that rely on RIP_REL_REF() today)
