On Fri, 2025-07-04 at 11:28 -0700, Eduard Zingerman wrote:
> 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.
Maybe just add __arg_untrusted_local and avoid ambiguity?
[...]
