Re: [PATCH] module/ksymtab: use 64-bit relative reference for target symbol

From: Ard Biesheuvel
Date: Thu May 23 2019 - 04:44:35 EST




On 5/22/19 5:28 PM, Ard Biesheuvel wrote:


On 5/22/19 4:02 PM, Ard Biesheuvel wrote:
The following commit

ÂÂ 7290d5809571 ("module: use relative references for __ksymtab entries")

updated the ksymtab handling of some KASLR capable architectures
so that ksymtab entries are emitted as pairs of 32-bit relative
references. This reduces the size of the entries, but more
importantly, it gets rid of statically assigned absolute
addresses, which require fixing up at boot time if the kernel
is self relocating (which takes a 24 byte RELA entry for each
member of the ksymtab struct).

Since ksymtab entries are always part of the same module as the
symbol they export (or of the core kernel), it was assumed at the
time that a 32-bit relative reference is always sufficient to
capture the offset between a ksymtab entry and its target symbol.

Unfortunately, this is not always true: in the case of per-CPU
variables, a per-CPU variable's base address (which usually differs
from the actual address of any of its per-CPU copies) could be at
an arbitrary offset from the ksymtab entry, and so it may be out
of range for a 32-bit relative reference.


(Apologies for the 3-act monologue)

This turns out to be incorrect. The symbol address of per-CPU variables exported by modules is always in the vicinity of __per_cpu_start, and so it is simply a matter of making sure that the core kernel is in range for module ksymtab entries containing 32-bit relative references.

When running the arm64 with kaslr enabled, we currently randomize the module space based on the range of ADRP/ADD instruction pairs, which have a -/+ 4 GB range rather than the -/+ 2 GB range of 32-bit place relative data relocations. So we can fix this by simply reducing the randomization window to 2 GB.

So please disregard this patch (and the followup one against arch/x86/tools)

--
Ard.