On Thu, Jan 27, 2022 at 02:59:31PM +0100, Ard Biesheuvel wrote: > On Thu, 27 Jan 2022 at 14:24, Mark Rutland <mark.rutl...@arm.com> wrote: > > > > On Thu, Jan 27, 2022 at 02:07:03PM +0100, Ard Biesheuvel wrote: > > > I suppose that on arm64, we can work around this by passing > > > --apply-dynamic-relocs to the linker, so that all R_AARCH64_RELATIVE > > > targets are prepopulated with the link time value of the respective > > > addresses. It does cause some bloat, which is why we disable that > > > today, but we could make that dependent on ftrace being enabled. > > > > We'd also need to teach the build-time sort to update the relocations, > > unless > > you mean to also change the boot-time reloc code to RMW with the offset? > > Why would that be necessary? Every RELA entry has the same effect on > its target address, as it just adds a fixed offset.
Currently in relocate_kernel() we generate the absolute address from the relocation alone, with the core of the relocation logic being as follows, with x9 being the pointer to a RELA entry, and x23 being the offset relative to the default load address: ldp x12, x13, [x9], #24 ldr x14, [x9, #-8] add x14, x14, x23 // relocate str x14, [x12, x23] ... and (as per another reply), a sample RELA entry currently contains: 0xffff8000090b1ab0 // default load VA of pointer to update 0x0000000000000403 // R_AARCH64_RELATIVE 0xffff8000090b6000 // default load VA of addr to write So either: * That code stays as-is, and we must update the relocs to correspond to their new sorted locations, or we'll blat the sorted values with the original relocs as we do today. * The code needs to change to RMW: read the existing value, add the offset (ignoring the content of the RELA entry's addend field), and write it back. This is what I meant when I said "change the boot-time reloc code to RMW with the offset". Does that make sense, or have I misunderstood? Thanks, Mark.