Re: [PATCH bpf-next v2 1/2] bpf: Add KF_OBTAIN for obtaining objects without reference count

[Alexei Starovoitov]

On Wed, Aug 28, 2024 at 1:05 PM Juntong Deng <juntong.deng@xxxxxxxxxxx> wrote:
>
>  static bool is_kfunc_sleepable(struct bpf_kfunc_call_arg_meta *meta)
> @@ -12845,6 +12851,12 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>                         /* For mark_ptr_or_null_reg, see 93c230e3f5bd6 */
>                         regs[BPF_REG_0].id = ++env->id_gen;
>                 }
> +
> +               if (is_kfunc_obtain(&meta)) {
> +                       regs[BPF_REG_0].type |= PTR_TRUSTED;
> +                       regs[BPF_REG_0].ref_obj_id = meta.ref_obj_id;
> +               }

The long term plan for the verifier is to do KF_TRUSTED_ARGS
by default in all kfuncs.
In that sense a PTR_TO_BTF_ID returned from a kfunc
has to be either trusted/rcu or acquired.
Currently we have only one odd set of kfuncs iter_next() that
return old/deprecated style PTR_TO_BTF_ID without either TRUSTED
or UNTRUSTED flag.
That is being fixed. They will become TRUSTED | RCU.
After that all new kfuncs should be reviewed from point of view
whether structs that they return either trusted|rcu.
So KF_OBTAIN is partially unnecessary.

But what you want to achieve with KF_OBTAIN is more than just TRUSTED.
You want to propagate ref_obj_id and we cannot do that.
When types change they cannot have the same ref_obj_id.
Think of sock_from_file(). If we add such a wrapper as a kfunc
it will be returning a different object.
(struct *)file != (struct sock *)file->private_data
They has to have different ids.

The patch 2 is just buggy:
+struct mm_struct *bpf_kfunc_obtain_test(struct task_struct *task)
+{
+       return task->mm;
+}

This is wrong:
- mm has to be refcnted. Acquiring a task doesn't mean that task->mm
stays valid.
- ref_obj_id cannot be copied. It's incorrect from verifier ref tracking pov.

pw-bot: cr