bpf, arm64: start flushing icache range from header

While recently going over ARM64's BPF code, I noticed that the icache range we're flushing should start at header already and not at ctx.image.

Reason is that after b569c1c622c5 ("net: bpf: arm64: address randomize and write protect JIT code"), we also want to make sure to flush the random-sized trap in front of the start of the actual program (analogous to x86). No operational differences from user side.

Signed-off-by Daniel Borkmann <[email protected]>

Acked-by Zi Shen Lim <[email protected]>

Cc Alexei Starovoitov <[email protected]>

---
( As arm64 jit fixes seem to go via arm64 tree, sending them here. )

 arch/arm64/net/bpf_jit_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/net/bpf_jit_comp.c +0 -0

index a44e529..ee06570 100644

Quoted 22 lines · Daniel Borkmann

While recently going over ARM64's BPF code, I noticed that the icache range we're flushing should start at header already and not at ctx.image.

Reason is that after b569c1c622c5 ("net: bpf: arm64: address randomize and write protect JIT code"), we also want to make sure to flush the random-sized trap in front of the start of the actual program (analogous to x86). No operational differences from user side.

Signed-off-by Daniel Borkmann <[email protected]>

Acked-by Zi Shen Lim <[email protected]>

Cc Alexei Starovoitov <[email protected]>

---
( As arm64 jit fixes seem to go via arm64 tree, sending them here. )

  arch/arm64/net/bpf_jit_comp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/net/bpf_jit_comp.c +0 -0

index a44e529..ee06570 100644

arch/arm64/net/bpf_jit_comp.c void bpf_int_jit_compile(struct bpf_prog *prog) · line 743

Quoted 5 lines

arch/arm64/net/bpf_jit_comp.c +1 -1

@@ -740,7 +740,7 @@ void bpf_int_jit_compile(struct bpf_prog *prog)
  	if (bpf_jit_enable > 1)
  		bpf_jit_dump(prog->len, image_size, 2, ctx.image);
 
-	bpf_flush_icache(ctx.image, ctx.image + ctx.idx);
+	bpf_flush_icache(header, ctx.image + ctx.idx);

As far as I can see, ctx.idx doesn't take into account the size of the header, given we zero it after bpf_jit_binary_alloc, and increment it for each instruction.

So won't this prevent us from flushing the end of the image? Or did I miss something?

Quoted 33 lines · Mark Rutland

Quoted 22 lines · Daniel Borkmann

While recently going over ARM64's BPF code, I noticed that the icache range we're flushing should start at header already and not at ctx.image.

Reason is that after b569c1c622c5 ("net: bpf: arm64: address randomize and write protect JIT code"), we also want to make sure to flush the random-sized trap in front of the start of the actual program (analogous to x86). No operational differences from user side.

Signed-off-by Daniel Borkmann <[email protected]>

Acked-by Zi Shen Lim <[email protected]>

Cc Alexei Starovoitov <[email protected]>

---
( As arm64 jit fixes seem to go via arm64 tree, sending them here. )

 arch/arm64/net/bpf_jit_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/net/bpf_jit_comp.c +0 -0

index a44e529..ee06570 100644

arch/arm64/net/bpf_jit_comp.c void bpf_int_jit_compile(struct bpf_prog *prog) · line 743

Quoted 5 lines

arch/arm64/net/bpf_jit_comp.c +1 -1

@@ -740,7 +740,7 @@ void bpf_int_jit_compile(struct bpf_prog *prog)
 	if (bpf_jit_enable > 1)
 		bpf_jit_dump(prog->len, image_size, 2, ctx.image);
 
-	bpf_flush_icache(ctx.image, ctx.image + ctx.idx);
+	bpf_flush_icache(header, ctx.image + ctx.idx);

As far as I can see, ctx.idx doesn't take into account the size of the header, given we zero it after bpf_jit_binary_alloc, and increment it for each instruction.

Quoted 2 lines

So won't this prevent us from flushing the end of the image? Or did I miss something?

Nope, bpf_flush_icache() takes start and end pointer ... header starts before ctx.image on the linear buffer. Why should this prevent us from flushing the end of the image?

While recently going over ARM64's BPF code, I noticed that the icache range we're flushing should start at header already and not at ctx.image.

Reason is that after b569c1c622c5 ("net: bpf: arm64: address randomize and write protect JIT code"), we also want to make sure to flush the random-sized trap in front of the start of the actual program (analogous to x86). No operational differences from user side.

Signed-off-by Daniel Borkmann <[email protected]>

Acked-by Zi Shen Lim <[email protected]>

Cc Alexei Starovoitov <[email protected]>

---
( As arm64 jit fixes seem to go via arm64 tree, sending them here. )

I'm applying this directly, please CC: netdev on future patches to the BPF JIT's regardless of where you think the patch will be applied as it should be _REVIEWED_ on netdev regardless.