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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 9 Dec 2022 17:12:49 -0800 From: Martin KaFai Lau <martin.lau@...ux.dev> To: Stanislav Fomichev <sdf@...gle.com>, Toke Høiland-Jørgensen <toke@...hat.com> Cc: bpf@...r.kernel.org, ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, 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 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 <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? > > 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