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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Dec 2022 17:12:49 -0800
From:   Martin KaFai Lau <>
To:     Stanislav Fomichev <>,
        Toke Høiland-Jørgensen <>
Cc:,,,,,,,,,, David Ahern <>,
        Jakub Kicinski <>,
        Willem de Bruijn <>,
        Jesper Dangaard Brouer <>,
        Anatoly Burakov <>,
        Alexander Lobakin <>,
        Magnus Karlsson <>,
        Maryam Tahhan <>,,
Subject: Re: [xdp-hints] Re: [PATCH bpf-next v3 03/12] bpf: XDP metadata RX

On 12/9/22 4:42 PM, Martin KaFai Lau wrote:
> On 12/8/22 6:57 PM, Stanislav Fomichev wrote:
>> On Thu, Dec 8, 2022 at 4:07 PM Toke Høiland-Jørgensen <> wrote:
>>> Stanislav Fomichev <> writes:
>>>>> Another UX thing I ran into is that libbpf will bail out if it can't
>>>>> find the kfunc in the kernel vmlinux, even if the code calling the
>>>>> function is behind an always-false if statement (which would be
>>>>> eliminated as dead code from the verifier). This makes it a bit hard to
>>>>> conditionally use them. Should libbpf just allow the load without
>>>>> performing the relocation (and let the verifier worry about it), or
>>>>> should we have a bpf_core_kfunc_exists() macro to use for checking?
>>>>> Maybe both?
>>>> I'm not sure how libbpf can allow the load without performing the
>>>> relocation; maybe I'm missing something.
>>>> IIUC, libbpf uses the kfunc name (from the relocation?) and replaces
>>>> it with the kfunc id, right?
>>> Yeah, so if it can't find the kfunc in vmlinux, just write an id of 0.
>>> This will trip the check at the top of fixup_kfunc_call() in the
>>> verifier, but if the code is hidden behind an always-false branch (an
>>> rodata variable set to zero, say) the instructions should get eliminated
>>> before they reach that point. That way you can at least turn it off at
>>> runtime (after having done some kind of feature detection) without
>>> having to compile it out of your program entirely.
>>>> Having bpf_core_kfunc_exists would help, but this probably needs
>>>> compiler work first to preserve some of the kfunc traces in vmlinux.h?
> hmm.... if I follow correctly, it wants the libbpf to accept a bpf prog using a 
> kfunc that does not exist in the running kernel?
> Have you tried "__weak":
> extern void dummy_kfunc(void) __ksym __weak;
> SEC("tc")
> int load(struct __sk_buff *skb)
> {
>      if (dummy_kfunc) {

Sadly, won't work. only VAR is supported on ld.

>          dummy_kfunc();
>          return TC_ACT_SHOT;
>      }
>      return TC_ACT_UNSPEC;
> }

Powered by blists - more mailing lists