On 9/27/2022 4:29 AM, Daniel Borkmann wrote:
[ +Mark/Florent ]
On 9/19/22 11:21 AM, Xu Kuohai wrote:
From: Xu Kuohai <xukuohai@xxxxxxxxxx>
Currently BPF_CALL is always jited to indirect call, but when target is
in the range of direct call, BPF_CALL can be jited to direct call.
For example, the following BPF_CALL
call __htab_map_lookup_elem
is always jited to an indirect call:
mov x10, #0xffffffffffff18f4
movk x10, #0x821, lsl #16
movk x10, #0x8000, lsl #32
blr x10
When the target is in the range of direct call, it can be jited to:
bl 0xfffffffffd33bc98
This patch does such jit when possible.
1. First pass, get the maximum jited image size. Since the jited image
memory is not allocated yet, the distance between jited BPF_CALL
instructon and call target is unknown, so jit all BPF_CALL to indirect
call to get the maximum image size.
2. Allocate image memory with the size caculated in step 1.
3. Second pass, determine the jited address and size for every bpf instruction.
Since image memory is now allocated and there is only one jit method for
bpf instructions other than BPF_CALL, so the jited address for the first
BPF_CALL is determined, so the distance to call target is determined, so
the first BPF_CALL is determined to be jited to direct or indirect call,
so the jited image size after the first BPF_CALL is determined. By analogy,
the jited addresses and sizes for all subsequent BPF instructions are
determined.
4. Last pass, generate the final image. The jump offset of jump instruction
whose target is within the jited image is determined in this pass, since
the target instruction address may be changed in step 3.
Wouldn't this require similar convergence process like in x86-64 JIT? You state
the jump instructions are placed in step 4 because step 3 could have changed their
offsets, but then after step 4, couldn't also again the offsets have changed for
the target addresses from 3 again in some corner cases (given emit_a64_mov_i() is
used also in jump encoding)?
IIUC, the reason why there is a convergence process on x86 is that x86's jmp
instruction length varies with the size of immediate part, so after immediate
part is adjusted, the instruction length may change accordingly, and consequently
cause the positions of subsequent instructions to change, which in turn causes
the distance between instructions to change. However, arm64's instruction size
is fixed to 4 bytes and does not change with immediate part changes. So adjusting
the immediate part of arm64 jump instruction does not result in a change in
instruction length or position.
For BPF_CALL, arguments passed to emit_call() and emit_a64_mov_i() (if called)
do not change in pass 3 and 4, so the jited result does not change. This is also
true for other non-BPF_JMP instructions.
So no convergence is required on arm64.
Tested with test_bpf.ko and some arm64 working selftests, nothing failed.
[...]
