netdev - Re: [PATCH bpf-next v2 02/13] bpf: btf: Add BTF_KIND_FUNC and BTF_KIND_FUNC

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: <14c5120a-b67a-a514-5e9d-2895a4a841df@solarflare.com>
Date:   Thu, 8 Nov 2018 17:58:56 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Martin Lau <kafai@...com>, Yonghong Song <yhs@...com>,
        Alexei Starovoitov <ast@...com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next v2 02/13] bpf: btf: Add BTF_KIND_FUNC and
 BTF_KIND_FUNC_PROTO

On 07/11/18 21:49, Alexei Starovoitov wrote:
> On Wed, Nov 07, 2018 at 07:29:31PM +0000, Edward Cree wrote:
>> Whereas I don't, and I don't feel like my core criticisms have
>>  been addressed _at all_.  The only answer I get to "BTF should
>>  store type and instance information in separate records" is
>>  "it's a debuginfo",
> ...
>>  I am just trying to organise
>>  BTF to consist of separate _parts_ for types and instances,
>>  rather than forcing both into the same Procrustean bed.
> BTF does not have and should not have instances.
> BTF is debug info only.
> This is not negotiable.
I'm not saying the instances go in BTF, I'm saying that debug info
 *about* instances goes in BTF (it already does, as you keep saying
 BTF is "not just pure types"), and that that ought to be
 distinguished within the format from debug info about types.

> So I'm looking forward to your ideas how to describe BTF in .s
> Note such .s must have freedom to describe 'int bar(struct __sk_buff *a1, char a2)'
> as debug info while having '.globl foo; foo:' as symbol name.
I've pushed out a branch with what I have; see
 https://github.com/solarflarecom/ebpf_asm/tree/btfdoc
 (with some examples in dropper.s and documentation in the README).
In particular note that right now the BTF section is entirely
 decoupled from the .text, so indeed there is nothing right now
 tying function names to symbol names.  I do not yet have anything
 generating FuncInfo (or LineInfo) tables, but when I do that will
 remain decoupled.

> Your other 'criticism' was about libbpf's bpf_map_find_btf_info()
> and ____btf_map_* hack. Yes. It is a hack and I'm open to change it
> if there are better suggestions. It's a convention between
> libbpf and program writers that produce elf. It's not a kernel abi.
> Nothing to do with BTF and this instance vs debug info discussion.
It's everything to do with it: it's defining a type with a magic name
 (____btf_map_foo) when what we really want to do is declare an
 instance (the map 'foo').  And it may not be a kernel ABI, but it's
 a part of the file format you're defining (whether that's just a
 'convention' or something more), and if you want the BTF ecosystem
 to be more than just an llvm monoculture then the format needs to be
 properly specified so that others can work with it.

> Happy to jump on the call to explain it again.
> 10:30am pacific time works for me tomorrow.
That works for me (that's in ~30 minutes from now if I've converted
 correctly.)  Please email me offlist with the phone number to call.

-Ed