netdev - Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code simplification for RV64 JIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2281e59d-80d4-480f-894d-614d2160365b@huawei.com>
Date: Mon, 22 Jan 2024 23:15:00 +0800
From: Pu Lehui <pulehui@...wei.com>
To: Björn Töpel <bjorn@...nel.org>, Pu Lehui
	<pulehui@...weicloud.com>, <bpf@...r.kernel.org>,
	<linux-riscv@...ts.infradead.org>, <netdev@...r.kernel.org>
CC: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
	<daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
	<martin.lau@...ux.dev>, Song Liu <song@...nel.org>, Yonghong Song
	<yhs@...com>, John Fastabend <john.fastabend@...il.com>, KP Singh
	<kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>, Hao Luo
	<haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, Palmer Dabbelt
	<palmer@...belt.com>, Conor Dooley <conor@...nel.org>, Luke Nelson
	<luke.r.nels@...il.com>
Subject: Re: [PATCH RESEND bpf-next v3 0/6] Zbb support and code
 simplification for RV64 JIT



On 2024/1/22 22:44, Björn Töpel wrote:
> Pu Lehui <pulehui@...weicloud.com> writes:
> 
>> On 2024/1/22 22:33, Björn Töpel wrote:
>>> Pu Lehui <pulehui@...weicloud.com> writes:
>>>
>>>> Add Zbb support [0] to optimize code size and performance of RV64 JIT.
>>>> Meanwhile, adjust the code for unification and simplification. Tests
>>>> test_bpf.ko and test_verifier have passed, as well as the relative
>>>> testcases of test_progs*.
>>>>
>>>> Link: https://github.com/riscv/riscv-bitmanip/releases/download/1.0.0/bitmanip-1.0.0-38-g865e7a7.pdf [0]
>>>>
>>>> v3 resend:
>>>> - resend for mail be treated as spam.
>>>>
>>>> v3:
>>>> - Change to early-exit code style and make code more explicit.
>>>
>>> Lehui,
>>>
>>> Sorry for the delay. I'm chasing a struct_ops RISC-V BPF regression in
>>> 6.8-rc1, I will need to wrap my head around that prior reviewing
>>> properly.
>>>
>>
>> Oh, I also found the problem with struct ops and fixed it
> 
> Awesome, I just started bisecting the following test_progs sub-test
> fails on 6.8-rc1:
> 
> bpf_iter_setsockopt:
> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
> Oops [#1]
> Modules linked in: bpf_testmod(OE) drm fuse i2c_core dm_mod drm_panel_orientation_quirks backlight configfs ip_tables x_tables
> CPU: 1 PID: 458 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
> Hardware name: riscv-virtio,qemu (DT)
> epc : 0x0
>   ra : tcp_set_ca_state+0x2c/0x9a
> epc : 0000000000000000 ra : ffffffff80cdc6b2 sp : ff2000000000b910
>   gp : ffffffff82587b60 tp : ff60000087ea8040 t0 : 0000000000000000
>   t1 : ffffffff801ed15e t2 : 0000000000000000 s0 : ff2000000000b930
>   s1 : ff600000879296c0 a0 : ff20000000497000 a1 : 0000000000000008
>   a2 : 0000000000000001 a3 : ff60000087ea83a0 a4 : 0000000000000000
>   a5 : 0000000000000106 a6 : 0000000000000021 a7 : 0000000000000000
>   s2 : 0000000000000000 s3 : ff60000086878008 s4 : ff60000082ce2f40
>   s5 : ff60000084f56040 s6 : ff60000087929040 s7 : ff60000086878008
>   s8 : ff2000000000ba5f s9 : ff60000087928a00 s10: 0000000000000002
>   s11: ff60000087928040 t3 : 000000000001ffff t4 : 0100000000000000
>   t5 : 0000000000000000 t6 : ff6000008792a118
> status: 0000000200000120 badaddr: 0000000000000000 cause: 000000000000000c
> Code: Unable to access instruction at 0xffffffffffffffec.
> ---[ end trace 0000000000000000 ]---
> 
> bpf_tcp_ca:
> Unable to handle kernel paging request at virtual address ff60000088554500
> Oops [#1]
> Modules linked in: iptable_raw xt_connmark bpf_testmod(OE) drm fuse i2c_core drm_panel_orientation_quirks backlight dm_mod configfs ip_tables x_tables [last unloaded: bpf_testmod(OE)]
> CPU: 3 PID: 458 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
> Hardware name: riscv-virtio,qemu (DT)
> epc : 0xff60000088554500
>   ra : tcp_ack+0x288/0x1232
> epc : ff60000088554500 ra : ffffffff80cc7166 sp : ff2000000117ba50
>   gp : ffffffff82587b60 tp : ff60000087be0040 t0 : ff60000088554500
>   t1 : ffffffff801ed24e t2 : 0000000000000000 s0 : ff2000000117bbc0
>   s1 : 0000000000000500 a0 : ff20000000691000 a1 : 0000000000000018
>   a2 : 0000000000000001 a3 : ff60000087be03a0 a4 : 0000000000000000
>   a5 : 0000000000000000 a6 : 0000000000000021 a7 : ffffffff8263f880
>   s2 : 000000004ac3c13b s3 : 000000004ac3c13a s4 : 0000000000008200
>   s5 : 0000000000000001 s6 : 0000000000000104 s7 : ff2000000117bb00
>   s8 : ff600000885544c0 s9 : 0000000000000000 s10: ff60000086ff0b80
>   s11: 000055557983a9c0 t3 : 0000000000000000 t4 : 000000000000ffc4
>   t5 : ffffffff8154f170 t6 : 0000000000000030
> status: 0000000200000120 badaddr: ff60000088554500 cause: 000000000000000c
> Code: c796 67d7 0000 0000 0052 0002 c13b 4ac3 0000 0000 (0001) 0000
> ---[ end trace 0000000000000000 ]---
> 
> dummy_st_ops:
> Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000043022
> Oops [#1]
> Modules linked in: iptable_raw xt_connmark bpf_testmod(OE) drm fuse i2c_core drm_panel_orientation_quirks backlight dm_mod configfs ip_tables x_tables [last unloaded: bpf_testmod(OE)]
> CPU: 1 PID: 452 Comm: test_progs Tainted: G           OE      6.8.0-rc1-kselftest_plain #1
> Hardware name: riscv-virtio,qemu (DT)
> epc : 0x43022
>   ra : bpf_struct_ops_test_run+0x188/0x37a
> epc : 0000000000043022 ra : ffffffff80c75d1a sp : ff200000002a3ce0
>   gp : ffffffff82587b60 tp : ff6000008356b840 t0 : 0000000000043023
>   t1 : ffffffff801ed062 t2 : 000000000000ff00 s0 : ff200000002a3d40
>   s1 : ffffffff78207000 a0 : fffffffff2f3f4f5 a1 : 0000000000000008
>   a2 : 0000000000000001 a3 : ff6000008356bba0 a4 : 0000000000000000
>   a5 : fffffffff2f3f4f5 a6 : 0000000000000021 a7 : 0000000052464e43
>   s2 : 0000000000000000 s3 : ff60000080b33b80 s4 : 0000000000000084
>   s5 : ff60000083334c00 s6 : ff60000084861580 s7 : 00007ffff0887668
>   s8 : 00007fffaa859030 s9 : 0000000000000000 s10: 000055556631ca4c
>   s11: 000055556631c9c0 t3 : 000000000000000f t4 : 0000000000000800
>   t5 : 0001000000000000 t6 : ff6000008adb9bf8
> status: 0000000200000120 badaddr: 0000000000043022 cause: 000000000000000c
> Code: Unable to access instruction at 0x000000000004300e.
> ---[ end trace 0000000000000000 ]---
> 
> Environment: OpenSBI 1.4, Qemu 8.2.0, U-boot UEFI
> 
> Is that the same that you se >

Yes, is the same issue. The question is that the commit 2cd3e3772e41 
("x86/cfi,bpf: Fix bpf_struct_ops CFI") change func_addr of 
arch_prepare_bpf_trampoline from NULL to not NULL, while we use 
func_addr to distinguish struct_ops and regular trampoline. After commit 
2cd3e3772e41, we can use BPF_TRAMP_F_INDIRECT to distinguish them as it 
always be set in struct_ops.

> I'll take your patch for a spin!
> 
> 
> Björn