Re: [PATCH bpf-next v1 4/8] bpf: attribute __arg_untrusted for global function parameters

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2025-07-04 at 20:03 +0200, Kumar Kartikeya Dwivedi wrote:

[...]

> > @@ -7818,6 +7821,22 @@ int btf_prepare_func_args(struct bpf_verifier_env *env, int subprog)
> >                         sub->args[i].btf_id = kern_type_id;
> >                         continue;
> >                 }
> > +               if (tags & ARG_TAG_UNTRUSTED) {
> > +                       int kern_type_id;
> > +
> > +                       if (tags & ~ARG_TAG_UNTRUSTED) {
> > +                               bpf_log(log, "arg#%d untrusted cannot be combined with any other tags\n", i);
> > +                               return -EINVAL;
> > +                       }
> > +
> > +                       kern_type_id = btf_get_ptr_to_btf_id(log, i, btf, t);
> 
> So while this makes sense for trusted, I think for untrusted, we
> should allow types in program BTF as well.
> This is one of the things I think lacks in bpf_rdonly_cast as well, to
> be able to cast to types in program BTF.
> Say you want to reinterpret some kernel memory into your own type and
> access it using a struct in the program which is a different type.
> I think it makes sense to make this work.

Hi Kumar,

Thank you for the review.
Allowing local program BTF makes sense to me.
I assume we should first search in kernel BTF and fallback to program
BTF if nothing found. This way verifier might catch a program
accessing kernel data structure but having wrong assumptions about
field offsets (not using CO-RE). On the other hand, this might get
confusing if there is an accidental conflict between kernel data
structure name and program local data structure name.

Mechanically this would be a slightly bigger change,
as btf_prepare_func_args() does not record which BTF was used for a
parameter and always assumes vmlinux BTF.

> When I needed it in the past I just added a local new
> bpf_rdonly_cast_local variant that uses prog->btf for btf_id and moved
> on.
> 
> Supporting bpf_core_cast for both prog BTF and kernel BTF types is not
> trivial because we cannot disambiguate local vs kernel types.
> IIRC module BTF types probably don't work either but that's a different story.

I can add bpf_rdonly_cast_local() as a followup, do you remember
context in which you needed this?

[...]