Re: [RFC bpf-next 11/13] treewide: bpf: Export symbols used by verifier

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Tue, Apr 8, 2025 at 8:35 PM Daniel Xu <dxu@dxuuu.xyz> wrote:
>
> This commit EXPORT_SYMBOL_GPL()'s all the unresolved symbols from verifier.o.
> This is necessary to support loads and reloads of the verifier at
> runtime.
>
> The list of symbols was generated using:
>
>     nm -u kernel/bpf/verifier.o | grep -ve "__asan\|__ubsan\|__kasan" | awk '{print $2}'
>
> Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>
> ---
>  arch/x86/net/bpf_jit_comp.c |  2 ++
>  drivers/media/rc/bpf-lirc.c |  1 +
>  fs/bpf_fs_kfuncs.c          |  4 ++++
>  kernel/bpf/bpf_iter.c       |  1 +
>  kernel/bpf/bpf_lsm.c        |  5 +++++
>  kernel/bpf/bpf_struct_ops.c |  2 ++
>  kernel/bpf/btf.c            | 40 +++++++++++++++++++++++++++++++++++++
>  kernel/bpf/cgroup.c         |  4 ++++
>  kernel/bpf/core.c           | 29 +++++++++++++++++++++++++++
>  kernel/bpf/disasm.c         |  4 ++++
>  kernel/bpf/helpers.c        |  2 ++
>  kernel/bpf/local_storage.c  |  2 ++
>  kernel/bpf/log.c            | 12 +++++++++++
>  kernel/bpf/map_iter.c       |  1 +
>  kernel/bpf/memalloc.c       |  3 +++
>  kernel/bpf/offload.c        | 10 ++++++++++
>  kernel/bpf/syscall.c        |  7 +++++++
>  kernel/bpf/tnum.c           | 20 +++++++++++++++++++
>  kernel/bpf/token.c          |  1 +
>  kernel/bpf/trampoline.c     |  5 +++++
>  kernel/events/callchain.c   |  3 +++
>  kernel/trace/bpf_trace.c    |  9 +++++++++
>  lib/error-inject.c          |  2 ++
>  net/core/filter.c           | 26 ++++++++++++++++++++++++
>  net/core/xdp.c              |  2 ++
>  net/netfilter/nf_bpf_link.c |  1 +
>  26 files changed, 198 insertions(+)

Patches 1-10 look ok. Moving the code around and few targeted
exports are fine,
but this patch goes too far.
At least btf.c, log.c, tnum.c and may be others should be a part
of the module.
Then check_sock_access() can be refactored into callbacks
to avoid exports in filter.c
We can approach it from the pov of minimizing exports,
but such steps won't give us clarity on how portable such
modular verifier will be.
Other questions to answer is whether maps should be in the module too.
Modules can provide their kfuncs already, so existing kfuncs
can stay where they are.

Namespacing into "bpf_internal" as Stanislav suggested is
a good thing too with a warning somewhere in Documentation/bpf/
that these must only be used by the verifier.