| Message ID | 20190521134622.18358-1-bjorn.topel@gmail.com |
|---|---|
| State | Accepted |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | [bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32 | expand |
On 05/21/2019 03:46 PM, Björn Töpel wrote: > When using 32-bit subregisters (ALU32), the RISC-V JIT would not clear > the high 32-bits of the target register and therefore generate > incorrect code. > > E.g., in the following code: > > $ cat test.c > unsigned int f(unsigned long long a, > unsigned int b) > { > return (unsigned int)a & b; > } > > $ clang-9 -target bpf -O2 -emit-llvm -S test.c -o - | \ > llc-9 -mattr=+alu32 -mcpu=v3 > .text > .file "test.c" > .globl f > .p2align 3 > .type f,@function > f: > r0 = r1 > w0 &= w2 > exit > .Lfunc_end0: > .size f, .Lfunc_end0-f > > The JIT would not clear the high 32-bits of r0 after the > and-operation, which in this case might give an incorrect return > value. > > After this patch, that is not the case, and the upper 32-bits are > cleared. > > Reported-by: Jiong Wang <jiong.wang@netronome.com> > Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Was this missed because test_verifier did not have test coverage? If so, could you follow-up with alu32 test cases for it, so other JITs can be tracked for these kind of issue as well. We should probably have one for every alu32 alu op to make sure it's not forgotten anywhere. Thanks, Daniel
On Tue, 21 May 2019 at 16:02, Daniel Borkmann <daniel@iogearbox.net> wrote: > > On 05/21/2019 03:46 PM, Björn Töpel wrote: > > When using 32-bit subregisters (ALU32), the RISC-V JIT would not clear > > the high 32-bits of the target register and therefore generate > > incorrect code. > > > > E.g., in the following code: > > > > $ cat test.c > > unsigned int f(unsigned long long a, > > unsigned int b) > > { > > return (unsigned int)a & b; > > } > > > > $ clang-9 -target bpf -O2 -emit-llvm -S test.c -o - | \ > > llc-9 -mattr=+alu32 -mcpu=v3 > > .text > > .file "test.c" > > .globl f > > .p2align 3 > > .type f,@function > > f: > > r0 = r1 > > w0 &= w2 > > exit > > .Lfunc_end0: > > .size f, .Lfunc_end0-f > > > > The JIT would not clear the high 32-bits of r0 after the > > and-operation, which in this case might give an incorrect return > > value. > > > > After this patch, that is not the case, and the upper 32-bits are > > cleared. > > > > Reported-by: Jiong Wang <jiong.wang@netronome.com> > > Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") > > Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> > > Was this missed because test_verifier did not have test coverage? Yup, and Jiong noted it. > If so, could you follow-up with alu32 test cases for it, so other > JITs can be tracked for these kind of issue as well. We should > probably have one for every alu32 alu op to make sure it's not > forgotten anywhere. > I'll hack a test_verifier test right away. Thanks, Björn > Thanks, > Daniel
On 05/21/2019 04:12 PM, Björn Töpel wrote: > On Tue, 21 May 2019 at 16:02, Daniel Borkmann <daniel@iogearbox.net> wrote: >> On 05/21/2019 03:46 PM, Björn Töpel wrote: >>> When using 32-bit subregisters (ALU32), the RISC-V JIT would not clear >>> the high 32-bits of the target register and therefore generate >>> incorrect code. >>> >>> E.g., in the following code: >>> >>> $ cat test.c >>> unsigned int f(unsigned long long a, >>> unsigned int b) >>> { >>> return (unsigned int)a & b; >>> } >>> >>> $ clang-9 -target bpf -O2 -emit-llvm -S test.c -o - | \ >>> llc-9 -mattr=+alu32 -mcpu=v3 >>> .text >>> .file "test.c" >>> .globl f >>> .p2align 3 >>> .type f,@function >>> f: >>> r0 = r1 >>> w0 &= w2 >>> exit >>> .Lfunc_end0: >>> .size f, .Lfunc_end0-f >>> >>> The JIT would not clear the high 32-bits of r0 after the >>> and-operation, which in this case might give an incorrect return >>> value. >>> >>> After this patch, that is not the case, and the upper 32-bits are >>> cleared. >>> >>> Reported-by: Jiong Wang <jiong.wang@netronome.com> >>> Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") >>> Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> >> >> Was this missed because test_verifier did not have test coverage? > > Yup, and Jiong noted it. Applied, thanks!
diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp.c index 80b12aa5e10d..e5c8d675bd6e 100644 --- a/arch/riscv/net/bpf_jit_comp.c +++ b/arch/riscv/net/bpf_jit_comp.c @@ -759,14 +759,20 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx, case BPF_ALU | BPF_AND | BPF_X: case BPF_ALU64 | BPF_AND | BPF_X: emit(rv_and(rd, rd, rs), ctx); + if (!is64) + emit_zext_32(rd, ctx); break; case BPF_ALU | BPF_OR | BPF_X: case BPF_ALU64 | BPF_OR | BPF_X: emit(rv_or(rd, rd, rs), ctx); + if (!is64) + emit_zext_32(rd, ctx); break; case BPF_ALU | BPF_XOR | BPF_X: case BPF_ALU64 | BPF_XOR | BPF_X: emit(rv_xor(rd, rd, rs), ctx); + if (!is64) + emit_zext_32(rd, ctx); break; case BPF_ALU | BPF_MUL | BPF_X: case BPF_ALU64 | BPF_MUL | BPF_X:
When using 32-bit subregisters (ALU32), the RISC-V JIT would not clear the high 32-bits of the target register and therefore generate incorrect code. E.g., in the following code: $ cat test.c unsigned int f(unsigned long long a, unsigned int b) { return (unsigned int)a & b; } $ clang-9 -target bpf -O2 -emit-llvm -S test.c -o - | \ llc-9 -mattr=+alu32 -mcpu=v3 .text .file "test.c" .globl f .p2align 3 .type f,@function f: r0 = r1 w0 &= w2 exit .Lfunc_end0: .size f, .Lfunc_end0-f The JIT would not clear the high 32-bits of r0 after the and-operation, which in this case might give an incorrect return value. After this patch, that is not the case, and the upper 32-bits are cleared. Reported-by: Jiong Wang <jiong.wang@netronome.com> Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> --- arch/riscv/net/bpf_jit_comp.c | 6 ++++++ 1 file changed, 6 insertions(+)