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
