Re: [PATCH bpf-next v5 3/5] bpf: Add helper to detect indirect jump targets

[Xu Kuohai]

On 3/4/2026 11:37 PM, Alexei Starovoitov wrote:
> On Wed, Mar 4, 2026 at 4:46 AM Xu Kuohai <xukuohai@xxxxxxxxxxxxxxx> wrote:
> > On 3/4/2026 1:19 AM, Alexei Starovoitov wrote:
> >
> > [...]
> >
> > > > -       for (i = 0; i < insn_cnt; i++, insn++) {
> > > > +       for (i = 0, j = 0; i < insn_cnt; i++, j++, insn++) {
> > > > +               env->insn_aux_data[subprog_start + j].final_idx = i;
> > > >                   if (bpf_pseudo_func(insn)) {
> > > >                           /* ld_imm64 with an address of bpf subprog is not
> > > >                            * a user controlled constant. Don't randomize it,
> > > > @@ -1512,6 +1542,8 @@ struct bpf_prog *bpf_jit_blind_constants(struct bpf_verifier_env *env, struct bp
> > > >                            */
> > > >                           insn++;
> > > >                           i++;
> > > > +                       j++;
> > > > +                       env->insn_aux_data[subprog_start + j].final_idx = i;
> > >
> > > You're adding final_idx because bpf_jit_blind_constants()
> > > doesn't call adjust_insn_aux_data() ?
> >
> > Yes, I added final_idx because insn_aux is not updated here.
> >
> > > imo that's an ugly workaround. Just call adjust_insn_aux_data().
> >
> > If we adjust the env->insn_aux_data here, should we also adjust the global
> > env->prog->insnsi array? I think env->insn_aux_data should remain consistent
> > with the global env->prog->insnsi array. Since constant blinding only rewrites
> > the subprog's private instruction array, updating the env->insn_aux_data
> > causes a mismatch with the global state.
>
> yes, and subprog starts, and pokes that bpf_patch_insn_data() do.
>
> blinding was implemented long before that, so it was never updated.

I see. Since env->prog->insnsi is rewritten by blind_constants now, would it
make sense to move constant blinding to the beginning of jit_subprogs, just
before the global instruction array is split into subprog copies?

This would eliminate the need to invoke constant blinding per subprog from
the arch-specific JIT, simplifying the overall flow.