On Thu, Apr 20, 2023 at 11:38 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Apr 20, 2023 at 12:14:10AM -0700, Joanne Koong wrote: > > return obj; > > @@ -2369,6 +2394,7 @@ BTF_ID_FLAGS(func, bpf_dynptr_slice_rdwr, KF_RET_NULL) > > BTF_ID_FLAGS(func, bpf_iter_num_new, KF_ITER_NEW) > > BTF_ID_FLAGS(func, bpf_iter_num_next, KF_ITER_NEXT | KF_RET_NULL) > > BTF_ID_FLAGS(func, bpf_iter_num_destroy, KF_ITER_DESTROY) > > +BTF_ID_FLAGS(func, bpf_dynptr_adjust) > > I've missed this earlier. > Shouldn't we change all the existing dynptr kfuncs to be KF_TRUSTED_ARGS? > Otherwise when people start passing bpf_dynptr-s from kernel code > (like fuse-bpf is planning to do) > the bpf prog might get vanilla ptr_to_btf_id to bpf_dynptr_kern. > It's probably not possible right now, so not a high-pri issue, but still. > Or something in the verifier makes sure that dynptr-s are all trusted? In my understanding, the checks the verifier enforces for KF_TRUSTED_ARGS are that the reg->offset is 0 and the reg may not be null. The verifier logic does this for dynptrs currently, it enforces that reg->offset is 0 (in stack_slot_obj_get_spi()) and that the reg->type is PTR_TO_STACK or CONST_PTR_TO_DYNPTR (in check_kfunc_args() for KF_ARG_PTR_TO_DYNPTR case). But maybe it's a good idea to add the KF_TRUSTED_ARGS flag anyways in case more safety checks are added to KF_TRUSTED_ARGS in the future?
