netdev - Re: [PATCH bpf-next 0/4] libbpf: add raw BTF type dumping

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: <20200930031809.lto7v7e7vtyivjon@ast-mbp.dhcp.thefacebook.com>
Date:   Tue, 29 Sep 2020 20:18:09 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 0/4] libbpf: add raw BTF type dumping

On Tue, Sep 29, 2020 at 05:44:48PM -0700, Andrii Nakryiko wrote:
> On Tue, Sep 29, 2020 at 5:03 PM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Tue, Sep 29, 2020 at 04:28:39PM -0700, Andrii Nakryiko wrote:
> > > Add btf_dump__dump_type_raw() API that emits human-readable low-level BTF type
> > > information, same as bpftool output. bpftool is not switched to this API
> > > because bpftool still needs to perform all the same BTF type processing logic
> > > to do JSON output, so benefits are pretty much zero.
> >
> > If the only existing user cannot actually use such api it speaks heavily
> > against adding such api to libbpf. Comparing strings in tests is nice, but
> > could be done with C output just as well.
> 
> It certainly can, it just won't save much code, because bpftool would
> still need to have a big switch over BTF type kinds to do JSON output.

So you're saying that most of the dump_btf_type() in bpftool/btf.c will stay as-is.
Only 'if (json_output)' will become unconditional? Hmm.
I know you don't want json in libbpf, but I think it's the point of
making a call on such things. Either libbpf gets to dump both
json and text dump_btf_type()-like output or it stays with C only.
Doing C and this text and not doing json is inconsistent.
Either libbpf can print btf in many different ways or it stays with C.
2nd format is not special in any way.
I don't think that text and json formats bring much value comparing to C,
so I would be fine with C only. But if we allow 2nd format we should
do json at the same time too to save bpftool the hassle.
And in the future we should allow 4th and 5th formats.