On Thu, 27 Jan 2022 at 15:55, Mark Rutland <mark.rutl...@arm.com> wrote: > > 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? >
No you're right. We'd have to use different sequences here depending on whether the relocation target is populated or not, which currently we don't care about.