[PATCH bpf-next] libbpf: fix AF_XDP helper program to support kernels without the JMP32 eBPF instruction class

[PATCH bpf-next] libbpf: fix AF_XDP helper program to support kernels without the JMP32 eBPF instruction class

[Alex Forster]

Kernel 5.1 introduced support for the JMP32 eBPF instruction class, and commit d7d962a modified the libbpf AF_XDP helper program to use the BPF_JMP32_IMM instruction. For those on earlier kernels, attempting to load the helper program now results in the verifier failing with "unknown opcode 66". This change replaces the usage of BPF_JMP32_IMM with BPF_JMP_IMM for compatibility with pre-5.1 kernels.

Signed-off-by: Alex Forster <aforster@cloudflare.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Björn Töpel <bjorn.topel@intel.com>
---
 tools/lib/bpf/xsk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
index 8e0ffa800a71..761f8485b80e 100644
--- a/tools/lib/bpf/xsk.c
+++ b/tools/lib/bpf/xsk.c
@@ -366,7 +366,7 @@ static int xsk_load_xdp_prog(struct xsk_socket *xsk)
 		/* call bpf_redirect_map */
 		BPF_EMIT_CALL(BPF_FUNC_redirect_map),
 		/* if w0 != 0 goto pc+13 */
-		BPF_JMP32_IMM(BPF_JSGT, BPF_REG_0, 0, 13),
+		BPF_JMP_IMM(BPF_JSGT, BPF_REG_0, 0, 13),
 		/* r2 = r10 */
 		BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
 		/* r2 += -4 */
-- 
2.23.0

Re: [PATCH bpf-next] libbpf: fix AF_XDP helper program to support kernels without the JMP32 eBPF instruction class

[Alexei Starovoitov]

On Thu, Dec 19, 2019 at 12:16 PM Alex Forster <aforster@cloudflare.com> wrote:
>
> Kernel 5.1 introduced support for the JMP32 eBPF instruction class, and commit d7d962a modified the libbpf AF_XDP helper program to use the BPF_JMP32_IMM instruction. For those on earlier kernels, attempting to load the helper program now results in the verifier failing with "unknown opcode 66". This change replaces the usage of BPF_JMP32_IMM with BPF_JMP_IMM for compatibility with pre-5.1 kernels.

I though af_xdp landed after jmp32 ?

Re: [PATCH bpf-next] libbpf: fix AF_XDP helper program to support kernels without the JMP32 eBPF instruction class

[Alex Forster]

> I though af_xdp landed after jmp32 ?

They were indeed pretty close together, but AF_XDP became usable in
late 2018 with either 4.18 or 4.19. JMP32 landed in early 2019 with
5.1.

Alex Forster

Re: [PATCH bpf-next] libbpf: fix AF_XDP helper program to support kernels without the JMP32 eBPF instruction class

[Björn Töpel]

On 2019-12-19 23:29, Alex Forster wrote:
>> I though af_xdp landed after jmp32 ?
> 
> They were indeed pretty close together, but AF_XDP became usable in
> late 2018 with either 4.18 or 4.19. JMP32 landed in early 2019 with
> 5.1.
>

Correct, but is anyone really using AF_XDP pre-5.1?

The rationale for doing JMP32:
https://lore.kernel.org/bpf/87v9sip0i8.fsf@toke.dk/

I think going forward, a route where different AF_XDP programs is loaded
based on what currently running kernel supports. "Every s^Hcycle is
sacred", and we're actually paying for the extra checks.

Then again, failing to load is still pretty bad. :-) Thanks for fixing this.


Acked-by: Björn Töpel <bjorn.topel@intel.com>


> Alex Forster
> 

Re: [PATCH bpf-next] libbpf: fix AF_XDP helper program to support kernels without the JMP32 eBPF instruction class

[Daniel Borkmann]

On 12/20/19 8:20 AM, Björn Töpel wrote:
> On 2019-12-19 23:29, Alex Forster wrote:
>>> I though af_xdp landed after jmp32 ?
>>
>> They were indeed pretty close together, but AF_XDP became usable in
>> late 2018 with either 4.18 or 4.19. JMP32 landed in early 2019 with
>> 5.1.
> 
> Correct, but is anyone really using AF_XDP pre-5.1?
> 
> The rationale for doing JMP32:
> https://lore.kernel.org/bpf/87v9sip0i8.fsf@toke.dk/
> 
> I think going forward, a route where different AF_XDP programs is loaded
> based on what currently running kernel supports. "Every s^Hcycle is
> sacred", and we're actually paying for the extra checks.
> 
> Then again, failing to load is still pretty bad. :-) Thanks for fixing this.

Could we simply just test availability of JMP32 in underlying kernel and use
it if available, if not, fall back to regular JMP. libbpf already has infra
for this, so xsk code could make use of it.

Thanks,
Daniel