netdev - Re: [PATCH bpf] bpf: support pre-2.25-binutils objcopy for vmlinux BTF

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] [day] [month] [year] [list]

Date:   Tue, 26 Nov 2019 14:47:47 -0800
From:   Stanislav Fomichev <sdf@...ichev.me>
To:     John Fastabend <john.fastabend@...il.com>
Cc:     Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, davem@...emloft.net, ast@...nel.org,
        daniel@...earbox.net
Subject: Re: [PATCH bpf] bpf: support pre-2.25-binutils objcopy for vmlinux
 BTF

On 11/26, John Fastabend wrote:
> Stanislav Fomichev wrote:
> > If vmlinux BTF generation fails, but CONFIG_DEBUG_INFO_BTF is set,
> > .BTF section of vmlinux is empty and kernel will prohibit
> > BPF loading and return "in-kernel BTF is malformed".
> > 
> > --dump-section argument to binutils' objcopy was added in version 2.25.
> > When using pre-2.25 binutils, BTF generation silently fails. Convert
> > to --only-section which is present on pre-2.25 binutils.
> 
> hmm I think we should fail hard if a feature explicitly asked for
> in the .config is not able to be built due to tooling. Otherwise
> users may later try to use a feature that can only be supported by
> BTF and that will have to fail at runtime. The runtime failure
> seems more likely to surprise users compared to the inconvience
> of having a compile time error. I view this similar to how having
> old ssl libs fails the build with the various signing options are
> set.
I agree. This is what actually happened to me. At some point
all my selftests started to fail.

> Can we print a useful help message instead so users can disable
> CONFIG_DEBUG_INFO_BTF or update binutils?
I'm not sure objcopy returns with error if it fails to execute the command.
I guess we can query the size of .BTF section in vmlinux and print
an error if it's empty.

Another thing we can do is to add a special 'data_size == 0' to
btf_parse_vmlinux. That way, at least, kernel can fall-back to
pre-BTF world instead of assuming that BTF is malformed (it's not
malformed, it's just not there). But that's, again, a surprise
at runtime. Checking at build time seems like a better option.