Re: [PATCH bpf-next v7 04/13] bpf: Add support for forcing kfunc args to be trusted

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 25 Jul 2022 at 11:52, Roberto Sassu <roberto.sassu@xxxxxxxxxx> wrote:
>
> > From: Kumar Kartikeya Dwivedi [mailto:memxor@xxxxxxxxx]
> > Sent: Thursday, July 21, 2022 3:43 PM
> > Teach the verifier to detect a new KF_TRUSTED_ARGS kfunc flag, which
> > means each pointer argument must be trusted, which we define as a
> > pointer that is referenced (has non-zero ref_obj_id) and also needs to
> > have its offset unchanged, similar to how release functions expect their
> > argument. This allows a kfunc to receive pointer arguments unchanged
> > from the result of the acquire kfunc.
> >
> > This is required to ensure that kfunc that operate on some object only
> > work on acquired pointers and not normal PTR_TO_BTF_ID with same type
> > which can be obtained by pointer walking. The restrictions applied to
> > release arguments also apply to trusted arguments. This implies that
> > strict type matching (not deducing type by recursively following members
> > at offset) and OBJ_RELEASE offset checks (ensuring they are zero) are
> > used for trusted pointer arguments.
> >
> > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx>
> > ---
> >  include/linux/btf.h | 32 ++++++++++++++++++++++++++++++++
> >  kernel/bpf/btf.c    | 17 ++++++++++++++---
> >  net/bpf/test_run.c  |  5 +++++
> >  3 files changed, 51 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/btf.h b/include/linux/btf.h
> > index 6dfc6eaf7f8c..cb63aa71e82f 100644
> > --- a/include/linux/btf.h
> > +++ b/include/linux/btf.h
> > @@ -17,6 +17,38 @@
> >  #define KF_RELEASE   (1 << 1) /* kfunc is a release function */
> >  #define KF_RET_NULL  (1 << 2) /* kfunc returns a pointer that may be NULL */
> >  #define KF_KPTR_GET  (1 << 3) /* kfunc returns reference to a kptr */
> > +/* Trusted arguments are those which are meant to be referenced arguments
> > with
> > + * unchanged offset. It is used to enforce that pointers obtained from acquire
> > + * kfuncs remain unmodified when being passed to helpers taking trusted args.
> > + *
> > + * Consider
> > + *   struct foo {
> > + *           int data;
> > + *           struct foo *next;
> > + *   };
> > + *
> > + *   struct bar {
> > + *           int data;
> > + *           struct foo f;
> > + *   };
> > + *
> > + *   struct foo *f = alloc_foo(); // Acquire kfunc
> > + *   struct bar *b = alloc_bar(); // Acquire kfunc
> > + *
> > + * If a kfunc set_foo_data() wants to operate only on the allocated object, it
> > + * will set the KF_TRUSTED_ARGS flag, which will prevent unsafe usage like:
> > + *
> > + *   set_foo_data(f, 42);       // Allowed
> > + *   set_foo_data(f->next, 42); // Rejected, non-referenced pointer
> > + *   set_foo_data(&f->next, 42);// Rejected, referenced, but bad offset
> > + *   set_foo_data(&b->f, 42);   // Rejected, referenced, but wrong type
> > + *
> > + * In the final case, usually for the purposes of type matching, it is deduced
> > + * by looking at the type of the member at the offset, but due to the
> > + * requirement of trusted argument, this deduction will be strict and not done
> > + * for this case.
> > + */
> > +#define KF_TRUSTED_ARGS (1 << 4) /* kfunc only takes trusted pointer
> > arguments */
>
> Hi Kumar
>
> would it make sense to introduce per-parameter flags? I have a function
> that has several parameters, but only one is referenced.
>

I have a patch for that in my local branch, I can fix it up and post
it. But first, can you give an example of where you think you need it?

> Thanks
>
> Roberto



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux