netdev - Re: [PATCH bpf-next 1/3] bpftool: add extra CO-RE mode to btf dump command

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]

Message-ID: <CAEf4BzY4ffWaeFckPuqNGNAU1uBG3TmTK+CjY1LVa2G+RGz=cA@mail.gmail.com>
Date:   Fri, 20 Dec 2019 21:40:17 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...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 1/3] bpftool: add extra CO-RE mode to btf dump command

On Fri, Dec 20, 2019 at 7:21 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Fri, Dec 20, 2019 at 09:40:31AM -0800, Andrii Nakryiko wrote:
> >
> > This one is a small line-number-wise. But the big difference between
> > `format c` and `format core` is that the latter assumes we are dumping
> > *vmlinux's BTF* for use with *BPF CO-RE from BPF side*. `format c`
> > doesn't make any assumptions and faithfully dumps whatever BTF
> > information is provided, which can be some other BPF program, or just
> > any userspace program, on which pahole -J was executed.
>
> When 'format c' was introduced it was specifically targeting CO-RE framework.

No it wasn't. Here's "motivational" part of BTF-to-C dump API patch set:

  "This patch set adds BTF-to-C dumping APIs to libbpf, allowing to output
  a subset of BTF types as a compilable C type definitions. This is useful by
  itself, as raw BTF output is not easy to inspect and comprehend. But it's also
  a big part of BPF CO-RE (compile once - run everywhere) initiative aimed at
  allowing to write relocatable BPF programs, that won't require on-the-host
  kernel headers (and would be able to inspect internal kernel structures, not
  exposed through kernel headers)."

And here's `format c` patch commit message:

  "Utilize new libbpf's btf_dump API to emit BTF as a C definitions."

It was never **just** for CO-RE framework, rather as a convenient
C-syntax view of BTF types.

> It is useful with BPF_CORE_READ macro and with builtin_preserve_access_index.
> Then we realized that both macro and builtin(({ ... })) are quite cumbersome to
> use and came with new clang attribute((preserve_access_index)) which makes
> programs read like normal C without any extra gotchas. Obviously it's nice if
> vmlinux.h already contains this attribute. Hence the need to either add extra
> flag to bpftool to emit this attribute or just emit it by default. So
> introducing new 'format core' (which is 99% the same as 'format c') and
> deprecating 'format c' to 'this is just .h dump of BTF' when it was around for
> few month only is absolutely no go. You need to find a way to extend 'format c'

I found the way, that's not the point of this discussion and
absolutely **not why** I'm adding `format core`. I feel like having
plain C dump of BTF is useful by itself (at least as a diagnostics
tool for BTF, similarly to objdump/readelf for ELF). But if no one
else cares, sure, I'll just reuse `format c` as CO-RE-specific BTF
dumper.

> without breaking existing users. Yes. Likely there are no such users, but that
> doesn't matter. Once new api is introduced we have to stick to it. 'format c'
> is such api.