netdev - Re: [RFC PATCH bpf-next 6/8] libbpf: allow specifying map definitions using 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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Jun 2019 23:27:36 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>
CC:     Stanislav Fomichev <sdf@...ichev.me>,
        Andrii Nakryiko <andriin@...com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>, Yonghong Song <yhs@...com>
Subject: Re: [RFC PATCH bpf-next 6/8] libbpf: allow specifying map definitions
 using BTF

On 6/6/19 4:02 PM, Andrii Nakryiko wrote:
>> struct {
>>          int type;
>>          int max_entries;
>> } my_map __attribute__((map(int,struct my_value))) = {
>>          .type = BPF_MAP_TYPE_ARRAY,
>>          .max_entries = 16,
>> };
>>
>> Of course this would need BPF backend support, but at least that approach
>> would be more C like. Thus this would define types where we can automatically
> I guess it's technically possible (not a compiler guru, but I don't
> see why it wouldn't be possible). But it will require at least two
> things:
> 1. Compiler support, obviously, as you mentioned.

every time we're doing llvm common change it takes many months.
Adding BTF took 6 month, though the common changes were trivial.
Now we're already 1+ month into adding 4 intrinsics to support CO-RE.

In the past I was very much in favor of extending __attribute__
with bpf specific stuff. Now not so much.
__attribute__((map(int,struct my_value))) cannot be done as strings.
clang has to process the types, create new objects inside debug info.
It's not clear to me how this modified debug info will be associated
with the variable my_map.
So I suspect doing __attribute__ with actual C type inside (())
will not be possible.
I think in the future we might still add string based attributes,
but it's not going to be easy.
So... Unless somebody in the community who is doing full time llvm work
will not step in right now and says "I will code the above attr stuff",
we should not count on such clang+llvm feature.