netdev - Re: [PATCH bpf-next 12/17] libbpf: support extern resolution for BTF-defined maps in .maps section

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:   Thu, 15 Apr 2021 13:57:17 -0700
From:   Alexei Starovoitov <ast@...com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Andrii Nakryiko <andrii@...nel.org>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH bpf-next 12/17] libbpf: support extern resolution for
 BTF-defined maps in .maps section

On 4/15/21 1:35 PM, Andrii Nakryiko wrote:
> 
> How about we start in the most restrictive way first. Each extern
> would need to specify all the attributes that should match the map
> definition. That includes max_entries. That way the typedef struct {
> ... } my_map_t re-use will work right out of the box. Later, if we see
> this is not sufficient, we can start relaxing the rules.

+1

>>
>> btw for signed progs I'm thinking to allow override of max_entries only,
>> since this attribute doesn't affect safety, correctness, behavior.
>> Meaning max_entries will and will not be part of a signature at the same time.
>> In other words it's necessary to support existing bcc/libbpf-tools.
>> If we go with 'allow max_entries in extern' that would match that behavior.
> 
> Ok, unless I misunderstood, allowing and checking all map attributes
> as a starting point should work, right?

yes. thanks!