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?
[...]
