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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 21 Jul 2021 08:59:19 -0600
From:   David Ahern <>
To:     Martynas Pumputis <>,
        Andrii Nakryiko <>
Cc:     Networking <>,
        Hangbin Liu <>,
        Stephen Hemminger <>,
        Daniel Borkmann <>
Subject: Re: [PATCH iproute2] libbpf: fix attach of prog with multiple

On 7/21/21 8:47 AM, Martynas Pumputis wrote:
>>> diff --git a/lib/bpf_libbpf.c b/lib/bpf_libbpf.c
>>> index d05737a4..f76b90d2 100644
>>> --- a/lib/bpf_libbpf.c
>>> +++ b/lib/bpf_libbpf.c
>>> @@ -267,10 +267,12 @@ static int load_bpf_object(struct bpf_cfg_in *cfg)
>>>          }
>>>          bpf_object__for_each_program(p, obj) {
>>> +               bool prog_to_attach = !prog && cfg->section &&
>>> +                       !strcmp(get_bpf_program__section_name(p),
>>> cfg->section);
>> This is still problematic, because one section can have multiple BPF
>> programs. I.e., it's possible two define two or more XDP BPF programs
>> all with SEC("xdp") and libbpf works just fine with that. I suggest
>> moving users to specify the program name (i.e., C function name
>> representing the BPF program). All the xdp_mycustom_suffix namings are
>> a hack and will be rejected by libbpf 1.0, so it would be great to get
>> a head start on fixing this early on.
> Thanks for bringing this up. Currently, there is no way to specify a
> function name with "tc exec bpf" (only a section name via the "sec"
> arg). So probably, we should just add another arg to specify the
> function name.
> It would be interesting to hear thoughts from iproute2 maintainers
> before fixing this.

maintaining backwards compatibility is a core principle for iproute2. If
we know of a libbpf change is going to cause a breakage then it is best
to fix it before any iproute2 release is affected.

Powered by blists - more mailing lists