2020-03-12 19:21 UTC+0100 ~ Daniel Borkmann <daniel@xxxxxxxxxxxxx>
> On 3/12/20 6:54 PM, Andrii Nakryiko wrote:
>> On Thu, Mar 12, 2020 at 8:38 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx>
>> wrote:
>>> On 3/12/20 3:03 PM, Quentin Monnet wrote:
>>>> When compiling bpftool with clang 7, after the addition of its recent
>>>> "bpftool prog profile" feature, Michal reported a segfault. This
>>>> occurred while the build process was attempting to generate the
>>>> skeleton needed for the profiling program, with the following command:
>>>>
>>>> ./_bpftool gen skeleton skeleton/profiler.bpf.o > profiler.skel.h
>>>>
>>>> Tracing the error showed that bpf_object__init_user_btf_maps() does no
>>>> verification on obj->btf before passing it to btf__get_nr_types(),
>>>> where
>>>> btf is dereferenced. Libbpf considers BTF information should be here
>>>> because of the presence of a ".maps" section in the object file (hence
>>>> the check on "obj->efile.btf_maps_shndx < 0" fails and we do not exit
>>>> from the function early), but it was unable to load BTF info as
>>>> there is
>>>> no .BTF section.
>>>>
>>>> Add a null pointer check and error out if the pointer is null. The
>>>> final
>>>> bpftool executable still fails to build, but at least we have a proper
>>>> error and no more segfault.
>>>>
>>>> Fixes: abd29c931459 ("libbpf: allow specifying map definitions using
>>>> BTF")
>>>> Cc: Andrii Nakryiko <andriin@xxxxxx>
>>>> Reported-by: Michal Rostecki <mrostecki@xxxxxxxxxxxx>
>>>> Signed-off-by: Quentin Monnet <quentin@xxxxxxxxxxxxx>
>>>
>>> Applied to bpf-next, thanks! Note ...
>>
>> I don't think this is the right fix. The problem was in my
>> 5327644614a1 ("libbpf: Relax check whether BTF is mandatory") commit.
>> I've removed "mandatory" status of BTF if .maps is present. But that's
>> not right. We have the need for BTF at two levels: for libbpf itself
>> and for kernel, those are overlapping, but not exactly the same. BTF
>> is needed for libbpf when .maps, .struct_ops and externs are present.
>> But kernel needs it only for when .struct_ops are present. Right now
>> those checks are conflated together. Proper fix would be to separate
>> them. Can we please undo this patch? I'll post a proper fix shortly.
>
> Ok, please send a proper fix for 5327644614a1 then. Tossed off the tree.
I suspected there was something like this and was only mildly satisfied
with my solution to be honest... Thank you Andrii for taking over!
Quentin
