lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 26 Jul 2022 12:58:33 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Kumar Kartikeya Dwivedi <memxor@...il.com>
CC:     "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        "Florian Westphal" <fw@...len.de>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        "Lorenzo Bianconi" <lorenzo@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>
Subject: RE: [PATCH bpf-next v7 04/13] bpf: Add support for forcing kfunc args
 to be trusted

> From: Kumar Kartikeya Dwivedi [mailto:memxor@...il.com]
> Sent: Tuesday, July 26, 2022 2:56 PM
> On Tue, 26 Jul 2022 at 12:02, Roberto Sassu <roberto.sassu@...wei.com>
> wrote:
> >
> > > From: Kumar Kartikeya Dwivedi [mailto:memxor@...il.com]
> > > Sent: Tuesday, July 26, 2022 11:30 AM
> > > On Mon, 25 Jul 2022 at 11:52, Roberto Sassu <roberto.sassu@...wei.com>
> > > wrote:
> > > >
> > > > > From: Kumar Kartikeya Dwivedi [mailto:memxor@...il.com]
> > > > > 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@...il.com>
> > > > > ---
> > > > >  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?
> >
> > I have pushed the complete patch set here, for testing:
> >
> > https://github.com/robertosassu/vmtest/tree/bpf-verify-sig-v9/travis-ci/diffs
> >
> > I rebased to bpf-next/master, and introduced KF_SLEEPABLE (similar
> > functionality of " btf: Add a new kfunc set which allows to mark
> > a function to be sleepable" from Benjamin Tissoires).
> >
> > The patch where I would use per-parameter KF_TRUSTED_ARGS is
> > number 8. I also used your new API in patch 7 and it works well.
> >
> 
> Ok, looks like you'll need it for the struct key * argument as there
> are multiple pointers in the argument list and not all of them need to
> be trusted. I will clean up and post the patch with a test later today
> to the list.

Yes, thanks a lot!

Roberto

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ