On Tue, Jul 14, 2020 at 11:33:33AM +0100, Russell King - ARM Linux admin wrote: > For 32-bit ARM, our bpf code uses "blx/bx" (or equivalent code > sequences) rather than encoding a "bl" or "b", so BPF there doesn't > care where the executable memory is mapped, and doesn't need any > PLTs. Given that, should bpf always allocate from the vmalloc() > region to preserve the module space for modules?
Ah, okay, then I suspect arm64 does something similar there. Thanks! > I'm more concerned about ftrace though, but only because I don't > have the understanding of that subsystem to really say whether there > are any side effects from having the allocations potentially be out > of range of a "bl" or "b" instruction. > > If ftrace jumps both to and from the allocated page using a "load > address to register, branch to register" approach like BPF does, then > ftrace should be safe - and again, raises the issue that maybe it > should always come from vmalloc() space. I think the problem with ftrace is patching multiple instruction; because it sounds like you'd need something to load the absolute address in a register and then jump to that. And where it's relatively easy to replace a single instruction, replace multiple instructions gets real tricky real quick. Which then leads to you being stuck with that 26bit displacement, IIRC.
