[Bug target/81863] [7 regression] -mword-relocations is unreliable

["ard.biesheuvel at linaro dot org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863

--- Comment #16 from ard.biesheuvel at linaro dot org ---
(In reply to Ramana Radhakrishnan from comment #15)
> (In reply to ard.biesheuvel from comment #13)
> > The kernel does not currently use -mword-relocations. We are looking into it
> > as an alternative to -fpic when building the kernel image as a PIE
> > executable so we can self-relocate at boot time. This allows for
> > randomization of the load offset (KASLR) which is an often requested
> > security feature.
> > 
> > The problem with -fpic (and even -fpie) is that the compiler infers from its
> > presence that you are building a shared library which requires preemptible
> > external symbols and should not contain any text relocations. None of these
> > concerns apply to the kernel, and the current workaround is to -include a .h
> > file that sets the visibility 'hidden' pragma, which is  a bit tedious.
> 
> I'm guessing you are aware of -fvisibility=hidden ?
> 

Yes, but that operates on definitions only, not on extern declarations. Using
the #pragma is the only thing that inhibits the emission of GOT-entry
generating relocations.

> > Since we are only interested in absolute references that are runtime
> > relocatable, -mword-relocations seems like the right choice, but it is
> > broken currently on v7 (due to this bug)
> 
> -mword-relocations is probably what you will need for v6t2 and onwards, yes
> and it's a feature that came in really for symbian / uClinux and thus
> doesn't get that widely tested.
> 
> I thought it was also used in kernel modules but my memory is foggy. Yeah ok
> - I can see where it's going and the same logic can be used everywhere.
> 

The module loader is not the issue here. This is strictly about the core kernel
image, which is fully linked (modules are simply partially linked objects so we
have to deal with several reloc types that a dynamic linker would never
encounter)

> > 
> > Ideally, we'd have some logic that takes -ffreestanding into account when
> > deciding how to deal with -fpie/-fpic
> 
> Uggh hmmm. Alternatively a -mlinux-kernel / -fpie / -fpic ? 
> 

Yes, something like that, and it makes sense to align with AArch64 here. For
the arm64 Linux KASLR kernel, we build a PIE executable from ordinary small
model objects. This works fine at present, but it would be nice to formalize
this in some way (IIRC we discussed this face to face in Bangkok last year)

> 
> > 
> > Also, when generating position independent code for v7 or later, we should
> > probably attempt to use place relative movw/movt pairs rather than relative
> > literals to emit PC relative references.
> 
> IIRC we struggle with the relocations .

I suppose the +/- 32 KB limit on the addend may be prohibitive here, but that
still only applies to symbols with static linkage. For symbols with
global/external linkage, this is not an issue, and in the kernel, those
references would not be indirected via a GOT entry (at least, not if we can
avoid it)