| 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
| ||
|
Message-ID: <43e6cd9f-ac54-46da-dba9-d535a2a77207@isovalent.com>
Date: Tue, 17 Jan 2023 15:42:54 +0000
From: Quentin Monnet <quentin@...valent.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>,
Tonghao Zhang <tong@...ragraf.org>,
Andrii Nakryiko <andrii@...nel.org>
Cc: Daniel Borkmann <daniel@...earbox.net>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"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>,
Hao Luo <haoluo@...gle.com>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...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" <naveen.n.rao@...ux.ibm.com>,
"mpe@...erman.id.au" <mpe@...erman.id.au>
Subject: Re: [bpf-next v2] bpf: drop deprecated bpf_jit_enable == 2
2023-01-17 14:55 UTC+0000 ~ Christophe Leroy <christophe.leroy@...roup.eu>
>
>
> Le 17/01/2023 à 15:41, Quentin Monnet a écrit :
>> [Vous ne recevez pas souvent de courriers de quentin@...valent.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>>
>> 2023-01-17 14:25 UTC+0000 ~ Christophe Leroy <christophe.leroy@...roup.eu>
>>>
>>>
>>> Le 17/01/2023 à 15:18, Tonghao Zhang a écrit :
>>>>
>>>>
>>>>> On Jan 17, 2023, at 7:36 PM, Christophe Leroy <christophe.leroy@...roup.eu> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Le 17/01/2023 à 08:30, Christophe Leroy a écrit :
>>>>>>
>>>>>>
>>>>>> Le 17/01/2023 à 06:30, Tonghao Zhang a écrit :
>>>>>>>
>>>>>>>
>>>>>>>> On Jan 9, 2023, at 4:15 PM, Christophe Leroy
>>>>>>>> <christophe.leroy@...roup.eu> wrote:
>>
>> [...]
>>
>>>>>>>> Sure I will try to test bpftool again in the coming days.
>>>>>>>>
>>>>>>>> Previous discussion about that subject is here:
>>>>>>>> https://patchwork.kernel.org/project/linux-riscv/patch/20210415093250.3391257-1-Jianlin.Lv@arm.com/#24176847=
>>
>> Christophe, apologies from dropping the discussion the last time, it
>> seems your last message on that thread didn't make it to my inbox at the
>> time :/. Thanks a lot for looking into that again!
>>
>>>>>>> Hi Christophe
>>>>>>> Any progress? We discuss to deprecate the bpf_jit_enable == 2 in 2021,
>>>>>>> but bpftool can not run on powerpc.
>>>>>>> Now can we fix this issue?
>>>>>>
>>>>>> Hi Tong,
>>>>>>
>>>>>> I have started to look at it but I don't have any fruitfull feedback yet.
>>>>>
>>>>> Hi Again,
>>>>>
>>>>> I tested again, the problem is still the same as one year ago:
>>>>>
>>>>> root@...ip:~# ./bpftool prog
>>>>> libbpf: elf: endianness mismatch in pid_iter_bpf.
>>>> It seem to be not right ehdr->e_ident[EI_DATA]. Do we can print the real value?
>>>> /*
>>>> * e_ident[EI_DATA]
>>>> */
>>>> #define ELFDATANONE 0
>>>> #define ELFDATA2LSB 1
>>>> #define ELFDATA2MSB 2
>>>> #define ELFDATANUM 3
>>>>
>>>> bpf_object__elf_init:
>>>> obj->efile.ehdr = ehdr = elf64_getehdr(elf);
>>>>
>>>>> libbpf: failed to initialize skeleton BPF object 'pid_iter_bpf': -4003
>>>>> Error: failed to open PID iterator skeleton
>>>>>
>>>>> root@...ip:~# uname -a
>>>>> Linux vgoip 6.2.0-rc3-02596-g1c2c9c13e256 #242 PREEMPT Tue Jan 17
>>>>> 09:36:08 CET 2023 ppc GNU/Linux
>>>> On my pc, elf is little endian.
>>>> # readelf -h tools/bpf/bpftool/pid_iter.bpf.o
>>>> ELF Header:
>>>> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>>>> Class: ELF64
>>>> Data: 2's complement, little endian # x86_64
>>>> Version: 1 (current)
>>>> OS/ABI: UNIX - System V
>>>> ABI Version: 0
>>>> Type: REL (Relocatable file)
>>>> Machine: Linux BPF
>>>> Version: 0x1
>>>> Entry point address: 0x0
>>>> Start of program headers: 0 (bytes into file)
>>>> Start of section headers: 64832 (bytes into file)
>>>> Flags: 0x0
>>>> Size of this header: 64 (bytes)
>>>> Size of program headers: 0 (bytes)
>>>> Number of program headers: 0
>>>> Size of section headers: 64 (bytes)
>>>> Number of section headers: 13
>>>> Section header string table index: 1
>>>>
>>>
>>> Yes, must be something wrong with the build, I get same as you :
>>>
>>> $ LANG= readelf -h pid_iter.bpf.o
>>> ELF Header:
>>> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>>> Class: ELF64
>>> Data: 2's complement, little endian
>>> Version: 1 (current)
>>> OS/ABI: UNIX - System V
>>> ABI Version: 0
>>> Type: REL (Relocatable file)
>>> Machine: Linux BPF
>>> Version: 0x1
>>> Entry point address: 0x0
>>> Start of program headers: 0 (bytes into file)
>>> Start of section headers: 34704 (bytes into file)
>>> Flags: 0x0
>>> Size of this header: 64 (bytes)
>>> Size of program headers: 0 (bytes)
>>> Number of program headers: 0
>>> Size of section headers: 64 (bytes)
>>> Number of section headers: 13
>>> Section header string table index: 1
>>>
>>>
>>> Whereas I expect the same as bpftool I suppose, which is :
>>>
>>> $ LANG= readelf -h bpftool
>>> ELF Header:
>>> Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
>>> Class: ELF32
>>> Data: 2's complement, big endian
>>> Version: 1 (current)
>>> OS/ABI: UNIX - System V
>>> ABI Version: 0
>>> Type: EXEC (Executable file)
>>> Machine: PowerPC
>>> Version: 0x1
>>> Entry point address: 0x100027d0
>>> Start of program headers: 52 (bytes into file)
>>> Start of section headers: 1842896 (bytes into file)
>>> Flags: 0x0
>>> Size of this header: 52 (bytes)
>>> Size of program headers: 32 (bytes)
>>> Number of program headers: 9
>>> Size of section headers: 40 (bytes)
>>> Number of section headers: 39
>>> Section header string table index: 38
>>>
>>
>> pid_iter.bpf.o should be generated from that command in bpftool's Makefile:
>>
>> $(OUTPUT)%.bpf.o: skeleton/%.bpf.c $(OUTPUT)vmlinux.h \
>> $(LIBBPF_BOOTSTRAP)
>> $(QUIET_CLANG)$(CLANG) \
>> -I$(or $(OUTPUT),.) \
>> -I$(srctree)/tools/include/uapi/ \
>> -I$(LIBBPF_BOOTSTRAP_INCLUDE) \
>> -g -O2 -Wall -fno-stack-protector \
>> -target bpf -c $< -o $@
>>
>> My understanding is that "-target bpf" is supposed to pick the
>> endianness for the host (see "llc --version | grep bpf". If that's not
>> the case, could you please try to turn that into '-target bpfeb' in the
>> Makefile instead? I'd be curious to see if it helps.
>>
>
> I guess it cannot work if it picks the endianness for the build host. It
> should pick the endianness for the target host.
>
> That's worse it seems with bpfeb : it fails at build :
>
> LINK /home/chleroy/linux-powerpc/tools/bpf/bpftool/bootstrap/bpftool
> GEN vmlinux.h
> CLANG pid_iter.bpf.o
> GEN pid_iter.skel.h
> libbpf: elf: endianness mismatch in pid_iter_bpf.
> Error: failed to open BPF object file: Endian mismatch
> make: *** [Makefile:222: pid_iter.skel.h] Error 93
>
>
> Complete build in case it helps:
>
> $ LANG= make CROSS_COMPILE=ppc-linux- ARCH=powerpc
>
> Auto-detecting system features:
> ... clang-bpf-co-re: [ .[32mon.[m ]
> ... llvm: [ .[31mOFF.[m ]
> ... libcap: [ .[31mOFF.[m ]
> ... libbfd: [ .[31mOFF.[m ]
[...]
> CLANG pid_iter.bpf.o
> GEN pid_iter.skel.h
> libbpf: elf: endianness mismatch in pid_iter_bpf.
> Error: failed to open BPF object file: Endian mismatch
> make: *** [Makefile:222: pid_iter.skel.h] Error 93
Right sorry, I forgot you were cross-compiling. As far as I understand,
it seems that bpftool's Makefile picks up the host endianness when
building the skeleton header file and embedding the BPF program in it,
so loading it on the target host doesn't work. We would like it to build
the skeleton with the target endianness instead, but it seems that
libbpf does not support that (referring to
bpf_object__check_endianness() in tools/lib/bpf/libbpf.c).
I don't know if there's a way to make libbpf work here, or plans to add
it (Andrii do you know?).
In the meantime, you could disable the use of skeletons in bpftool, by
removing "clang-bpf-co-re" from FEATURE_TESTS from the Makefile. You
should get a functional binary, which would only miss a few features
(namely, printing the pids of programs holding references to BPF
programs, and the "bpftool prog profile" command).
Powered by blists - more mailing lists