On Tue, 18 Oct 2022 at 07:23, Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote:
>
> On Sat, 15 Oct 2022 at 01:45, David Vernet <void@xxxxxxxxxxxxx> wrote:
> >
> > A previous change added a series of kfuncs for storing struct
> > task_struct objects as referenced kptrs. This patch adds a new
> > task_kfunc test suite for validating their expected behavior.
> >
> > Signed-off-by: David Vernet <void@xxxxxxxxxxxxx>
> > ---
> > [...]
> > +
> > +SEC("tp_btf/task_newtask")
> > +int BPF_PROG(task_kfunc_acquire_trusted_nested, struct task_struct *task, u64 clone_flags)
> > +{
> > + struct task_struct *acquired;
> > +
> > + if (!is_test_kfunc_task())
> > + return 0;
> > +
> > + /* Can't invoke bpf_task_acquire() on a trusted pointer at a nonzero offset. */
> > + acquired = bpf_task_acquire(task->last_wakee);
>
> The comment is incorrect, that would be &task->last_wakee instead,
> this is PTR_TO_BTF_ID | PTR_NESTED.
>
> > + if (!acquired)
> > + return 0;
> > + bpf_task_release(acquired);
> > +
> > + return 0;
> > +}
> > +
> > [...]
> > +
> > +static int test_acquire_release(struct task_struct *task)
> > +{
> > + struct task_struct *acquired;
> > +
> > + acquired = bpf_task_acquire(task);
>
> Unfortunately a side effect of this change is that now since
> PTR_TO_BTF_ID without ref_obj_id is considered trusted, the bpf_ct_*
> functions would begin working with tp_btf args. That probably needs to
> be fixed so that they reject them (ideally with a failing test case to
> make sure it doesn't resurface), probably with a new suffix __ref/or
> __owned as added here [0].
>
> Alexei, since you've suggested avoiding adding that suffix, do you see
> any other way out here?
> It's questionable whether bpf_ct_set_timeout/status should work for CT
> not owned by the BPF program.
>
> [0]: https://lore.kernel.org/bpf/dfb859a6b76a9234baa194e795ae89cb7ca5694b.1662383493.git.lorenzo@xxxxxxxxxx
>
Sorry for accidentally bumping this v3 thread instead of v5, whosoever
replies please continue there.
