Linux-RISC-V Archive on lore.kernel.org
 help / Atom feed
* [PATCH bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32
@ 2019-05-21 13:46 Björn Töpel
  2019-05-21 14:02 ` Daniel Borkmann
  0 siblings, 1 reply; 4+ messages in thread
From: Björn Töpel @ 2019-05-21 13:46 UTC (permalink / raw)
  To: daniel, ast, netdev; +Cc: Jiong Wang, Björn Töpel, linux-riscv, bpf

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(+)

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:
-- 
2.20.1


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32
  2019-05-21 13:46 [PATCH bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32 Björn Töpel
@ 2019-05-21 14:02 ` Daniel Borkmann
  2019-05-21 14:12   ` Björn Töpel
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Borkmann @ 2019-05-21 14:02 UTC (permalink / raw)
  To: Björn Töpel, ast, netdev; +Cc: Jiong Wang, linux-riscv, bpf

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32
  2019-05-21 14:02 ` Daniel Borkmann
@ 2019-05-21 14:12   ` Björn Töpel
  2019-05-23 13:58     ` Daniel Borkmann
  0 siblings, 1 reply; 4+ messages in thread
From: Björn Töpel @ 2019-05-21 14:12 UTC (permalink / raw)
  To: Daniel Borkmann; +Cc: Jiong Wang, Netdev, linux-riscv, bpf, Alexei Starovoitov

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32
  2019-05-21 14:12   ` Björn Töpel
@ 2019-05-23 13:58     ` Daniel Borkmann
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel Borkmann @ 2019-05-23 13:58 UTC (permalink / raw)
  To: Björn Töpel
  Cc: Jiong Wang, Netdev, linux-riscv, bpf, Alexei Starovoitov

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!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-21 13:46 [PATCH bpf] bpf, riscv: clear target register high 32-bits for and/or/xor on ALU32 Björn Töpel
2019-05-21 14:02 ` Daniel Borkmann
2019-05-21 14:12   ` Björn Töpel
2019-05-23 13:58     ` Daniel Borkmann

Linux-RISC-V Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \
		linux-riscv@lists.infradead.org infradead-linux-riscv@archiver.kernel.org
	public-inbox-index linux-riscv


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv


AGPL code for this site: git clone https://public-inbox.org/ public-inbox