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: <71c83f39-f85f-d990-95b7-ab6068839e6c@iogearbox.net>
Date:   Fri, 6 Jan 2023 16:37:31 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Christophe Leroy <christophe.leroy@...roup.eu>,
        "tong@...ragraf.org" <tong@...ragraf.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.or" 
        <linux-arm-kernel@...ts.infradead.or>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>
Cc:     Hao Luo <haoluo@...gle.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Song Liu <song@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Jiri Olsa <jolsa@...nel.org>, Hou Tao <houtao1@...wei.com>,
        KP Singh <kpsingh@...nel.org>, Yonghong Song <yhs@...com>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        naveen.n.rao@...ux.ibm.com, mpe@...erman.id.au
Subject: Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2

On 1/5/23 6:53 PM, Christophe Leroy wrote:
> Le 05/01/2023 à 04:06, tong@...ragraf.org a écrit :
>> From: Tonghao Zhang <tong@...ragraf.org>
>>
>> The x86_64 can't dump the valid insn in this way. A test BPF prog
>> which include subprog:
>>
>> $ llvm-objdump -d subprog.o
>> Disassembly of section .text:
>> 0000000000000000 <subprog>:
>>          0:       18 01 00 00 73 75 62 70 00 00 00 00 72 6f 67 00 r1 = 29114459903653235 ll
>>          2:       7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1
>>          3:       bf a1 00 00 00 00 00 00 r1 = r10
>>          4:       07 01 00 00 f8 ff ff ff r1 += -8
>>          5:       b7 02 00 00 08 00 00 00 r2 = 8
>>          6:       85 00 00 00 06 00 00 00 call 6
>>          7:       95 00 00 00 00 00 00 00 exit
>> Disassembly of section raw_tp/sys_enter:
>> 0000000000000000 <entry>:
>>          0:       85 10 00 00 ff ff ff ff call -1
>>          1:       b7 00 00 00 00 00 00 00 r0 = 0
>>          2:       95 00 00 00 00 00 00 00 exit
>>
>> kernel print message:
>> [  580.775387] flen=8 proglen=51 pass=3 image=ffffffffa000c20c from=kprobe-load pid=1643
>> [  580.777236] JIT code: 00000000: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
>> [  580.779037] JIT code: 00000010: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
>> [  580.780767] JIT code: 00000020: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
>> [  580.782568] JIT code: 00000030: cc cc cc
>>
>> $ bpf_jit_disasm
>> 51 bytes emitted from JIT compiler (pass:3, flen:8)
>> ffffffffa000c20c + <x>:
>>      0:   int3
>>      1:   int3
>>      2:   int3
>>      3:   int3
>>      4:   int3
>>      5:   int3
>>      ...
>>
>> Until bpf_jit_binary_pack_finalize is invoked, we copy rw_header to header
>> and then image/insn is valid. BTW, we can use the "bpftool prog dump" JITed instructions.
> 
> NACK.
> 
> Because the feature is buggy on x86_64, you remove it for all
> architectures ?
> 
> On powerpc bpf_jit_enable == 2 works and is very usefull.
> 
> Last time I tried to use bpftool on powerpc/32 it didn't work. I don't
> remember the details, I think it was an issue with endianess. Maybe it
> is fixed now, but it needs to be verified.
> 
> So please, before removing a working and usefull feature, make sure
> there is an alternative available to it for all architectures in all
> configurations.
> 
> Also, I don't think bpftool is usable to dump kernel BPF selftests.
> That's vital when a selftest fails if you want to have a chance to
> understand why it fails.

If this is actively used by JIT developers and considered useful, I'd be
ok to leave it for the time being. Overall goal is to reach feature parity
among (at least major arch) JITs and not just have most functionality only
available on x86-64 JIT. Could you however check what is not working with
bpftool on powerpc/32? Perhaps it's not too much effort to just fix it,
but details would be useful otherwise 'it didn't work' is too fuzzy.

Also, with regards to the last statement that bpftool is not usable to
dump kernel BPF selftests. Could you elaborate some more? I haven't used
bpf_jit_enable == 2 in a long time and for debugging always relied on
bpftool to dump xlated insns or JIT. Or do you mean by BPF selftests
the test_bpf.ko module? Given it has a big batch with kernel-only tests,
there I can see it's probably still useful.

Cheers,
Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ