netdev - Re: [xdp-hints] Re: [PATCH bpf-next v3 03/12] bpf: XDP metadata RX kfuncs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKH8qBsK1J5HeSgPN_sYzQRY2jZOO=-E+zyKsn4xJ22zv5HRFg@mail.gmail.com>
Date:   Thu, 8 Dec 2022 18:57:30 -0800
From:   Stanislav Fomichev <sdf@...gle.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
        andrii@...nel.org, martin.lau@...ux.dev, song@...nel.org,
        yhs@...com, john.fastabend@...il.com, kpsingh@...nel.org,
        haoluo@...gle.com, jolsa@...nel.org,
        David Ahern <dsahern@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Anatoly Burakov <anatoly.burakov@...el.com>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Magnus Karlsson <magnus.karlsson@...il.com>,
        Maryam Tahhan <mtahhan@...hat.com>, xdp-hints@...-project.net,
        netdev@...r.kernel.org
Subject: Re: [xdp-hints] Re: [PATCH bpf-next v3 03/12] bpf: XDP metadata RX kfuncs

On Thu, Dec 8, 2022 at 4:07 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>
> Stanislav Fomichev <sdf@...gle.com> 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?
>
> I am not sure how the existing macros work, TBH. Hopefully someone else
> can chime in :)

+1

I think we need to poke Andrii as a follow up :-)

> -Toke
>