Re: [RFC bpf-next 8/9] libbpf: support llvm-generated indirect jumps

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

On Mon, Jul 7, 2025 at 5:01 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Mon, 2025-07-07 at 16:49 -0700, Alexei Starovoitov wrote:
> > On Mon, Jul 7, 2025 at 4:45 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > >
> > > On Wed, 2025-06-18 at 15:08 +0000, Anton Protopopov wrote:
> > > > On 25/06/17 08:22PM, Alexei Starovoitov wrote:
> > > > > On Sun, Jun 15, 2025 at 1:55 AM Anton Protopopov
> > > > > <a.s.protopopov@gmail.com> wrote:
> > > > > >
> > > > > > The final line generates an indirect jump. The
> > > > > > format of the indirect jump instruction supported by BPF is
> > > > > >
> > > > > >     BPF_JMP|BPF_X|BPF_JA, SRC=0, DST=Rx, off=0, imm=fd(M)
> > > > > >
> > > > > > and, obviously, the map M must be the same map which was used to
> > > > > > init the register rX. This patch implements this in the following,
> > > > > > hacky, but so far suitable for all existing use-cases, way. On
> > > > > > encountering a `gotox` instruction libbpf tracks back to the
> > > > > > previous direct load from map and stores this map file descriptor
> > > > > > in the gotox instruction.
> > > > >
> > > > > ...
>
> [...]
>
> > > > >
> > > > > This is obviously broken and cannot be made smarter in libbpf.
> > > > > It won't be doing data flow analysis.
> > > > >
> > > > > The only option I see is to teach llvm to tag jmp_table in gotox.
> > > > > Probably the simplest way is to add the same relo to gotox insn
> > > > > as for ld_imm64. Then libbpf has a direct way to assign
> > > > > the same map_fd into both ld_imm64 and gotox.
> > > >
> > > > This would be nice.
> > >
> > > I did not implement this is a change for jt section + jt symbols.
> > > It can be added, but thinking about it again, are you sure it is
> > > necessary to have map fd in the gotox?
> > >
> > > Verifier should be smart enough already to track what map the rX in
> > > the `gotox rX` is a derivative of. It can make use of
> > > bpf_insn_aux_data->map_index to enforce that only one map is used with
> > > a particular gotox instruction.
> >
> > How would it associate gotox with map (set of IPs) at check_cfg() stage?
> > llvm needs to help.
>
> check_cfg(), right, thank you.
> But still, this feels like an artificial limitation.
> Just because we have a check_cfg() pass as a separate thing we need
> this hint.

and insn_successors().
All of them have to work before the main verifier analysis.