All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <kafai@fb.com>
To: Stanislav Fomichev <sdf@google.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, ast@kernel.org,
	daniel@iogearbox.net, andrii@kernel.org
Subject: Re: [PATCH bpf-next v8 06/11] bpf: allow writing to a subset of sock fields from lsm progtype
Date: Tue, 7 Jun 2022 15:17:56 -0700	[thread overview]
Message-ID: <20220607221756.ez4ntth5qnuev3ap@kafai-mbp> (raw)
In-Reply-To: <CAKH8qBv-cKrqvYjPh3P1JaWGLCTpBq3JtOEg+Py=a7BN_dVrPw@mail.gmail.com>

On Mon, Jun 06, 2022 at 03:46:29PM -0700, Stanislav Fomichev wrote:
> On Sat, Jun 4, 2022 at 12:18 AM Martin KaFai Lau <kafai@fb.com> wrote:
> >
> > On Wed, Jun 01, 2022 at 12:02:13PM -0700, Stanislav Fomichev wrote:
> > > For now, allow only the obvious ones, like sk_priority and sk_mark.
> > >
> > > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > > ---
> > >  kernel/bpf/bpf_lsm.c  | 58 +++++++++++++++++++++++++++++++++++++++++++
> > >  kernel/bpf/verifier.c |  3 ++-
> > >  2 files changed, 60 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
> > > index 83aa431dd52e..feba8e96f58d 100644
> > > --- a/kernel/bpf/bpf_lsm.c
> > > +++ b/kernel/bpf/bpf_lsm.c
> > > @@ -303,7 +303,65 @@ bool bpf_lsm_is_sleepable_hook(u32 btf_id)
> > >  const struct bpf_prog_ops lsm_prog_ops = {
> > >  };
> > >
> > > +static int lsm_btf_struct_access(struct bpf_verifier_log *log,
> > > +                                     const struct btf *btf,
> > > +                                     const struct btf_type *t, int off,
> > > +                                     int size, enum bpf_access_type atype,
> > > +                                     u32 *next_btf_id,
> > > +                                     enum bpf_type_flag *flag)
> > > +{
> > > +     const struct btf_type *sock_type;
> > > +     struct btf *btf_vmlinux;
> > > +     s32 type_id;
> > > +     size_t end;
> > > +
> > > +     if (atype == BPF_READ)
> > > +             return btf_struct_access(log, btf, t, off, size, atype, next_btf_id,
> > > +                                      flag);
> > > +
> > > +     btf_vmlinux = bpf_get_btf_vmlinux();
> > > +     if (!btf_vmlinux) {
> > > +             bpf_log(log, "no vmlinux btf\n");
> > > +             return -EOPNOTSUPP;
> > > +     }
> > > +
> > > +     type_id = btf_find_by_name_kind(btf_vmlinux, "sock", BTF_KIND_STRUCT);
> > > +     if (type_id < 0) {
> > > +             bpf_log(log, "'struct sock' not found in vmlinux btf\n");
> > > +             return -EINVAL;
> > > +     }
> > > +
> > > +     sock_type = btf_type_by_id(btf_vmlinux, type_id);
> > > +
> > > +     if (t != sock_type) {
> > > +             bpf_log(log, "only 'struct sock' writes are supported\n");
> > > +             return -EACCES;
> > > +     }
> > > +
> > > +     switch (off) {
> > > +     case bpf_ctx_range(struct sock, sk_priority):
> > This looks wrong.  It should not allow to write at
> > any bytes of the '__u32 sk_priority'.
> 
> SG, I'll change to offsetof() and will enfoce u32 size.
> 
> > > +             end = offsetofend(struct sock, sk_priority);
> > > +             break;
> > > +     case bpf_ctx_range(struct sock, sk_mark):
> > Same here.
> >
> > Just came to my mind,
> > if the current need is only sk_priority and sk_mark,
> > do you think allowing bpf_setsockopt will be more useful instead ?
> 
> For my use-case I only need sk_priority, but I was thinking that we
> can later extend that list as needed. But you suggestion to use
> bpf_setsockopt sounds good, let me try to use that. That might be
> better than poking directly into the fields.
semi-related.
bpf_setsockopt will have more options (and more useful) in the future.
I am thinking to refactor the bpf_setsockopt() to avoid duplicate
codes between the syscall setsockopt().  With sockptr_t, that may be
easier to do now.  It will then be easier to allow most of the options
in bpf_setsockopt().

> 
> > It currently has SO_MARK, SO_PRIORITY, and other options.
> > Also, changing SO_MARK requires to clear the sk->sk_dst_cache.
> > In general, is it safe to do bpf_setsockopt in all bpf_lsm hooks ?
> 
> It seems that we might need to more strictly control it (regardless of
> helper or direct field access). Not all lsm hooks lock sk argument, so
> we so maybe start with some allowlist of attach_btf_ids that can do
> bpf_setsockopt? (I'll add existing hooks that work on new/unreferenced
> or locked sockets to the list)
Yeah, it seems a btf id list is needed.  Regardless of bpf_setsockopt()
or not, locking the sk is needed to make changes.

  reply	other threads:[~2022-06-08  0:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-01 19:02 [PATCH bpf-next v8 00/11] bpf: cgroup_sock lsm flavor Stanislav Fomichev
2022-06-01 19:02 ` [PATCH bpf-next v8 01/11] bpf: add bpf_func_t and trampoline helpers Stanislav Fomichev
2022-06-01 19:02 ` [PATCH bpf-next v8 02/11] bpf: convert cgroup_bpf.progs to hlist Stanislav Fomichev
2022-06-01 19:02 ` [PATCH bpf-next v8 03/11] bpf: per-cgroup lsm flavor Stanislav Fomichev
2022-06-02  6:16   ` kernel test robot
2022-06-02 16:49     ` Stanislav Fomichev
2022-06-02 16:49       ` Stanislav Fomichev
2022-06-04  6:11   ` Martin KaFai Lau
2022-06-04  8:27     ` Martin KaFai Lau
2022-06-06 22:46       ` Stanislav Fomichev
2022-06-06 22:46     ` Stanislav Fomichev
2022-06-07 19:24       ` Martin KaFai Lau
2022-06-01 19:02 ` [PATCH bpf-next v8 04/11] bpf: minimize number of allocated lsm slots per program Stanislav Fomichev
2022-06-04  6:35   ` Martin KaFai Lau
2022-06-06 22:46     ` Stanislav Fomichev
2022-06-07 19:57       ` Martin KaFai Lau
2022-06-01 19:02 ` [PATCH bpf-next v8 05/11] bpf: implement BPF_PROG_QUERY for BPF_LSM_CGROUP Stanislav Fomichev
2022-06-04  6:59   ` Martin KaFai Lau
2022-06-04  8:05     ` Martin KaFai Lau
2022-06-06 22:46     ` Stanislav Fomichev
2022-06-07 20:44       ` Martin KaFai Lau
2022-06-01 19:02 ` [PATCH bpf-next v8 06/11] bpf: allow writing to a subset of sock fields from lsm progtype Stanislav Fomichev
2022-06-04  7:18   ` Martin KaFai Lau
2022-06-06 22:46     ` Stanislav Fomichev
2022-06-07 22:17       ` Martin KaFai Lau [this message]
2022-06-01 19:02 ` [PATCH bpf-next v8 07/11] libbpf: add lsm_cgoup_sock type Stanislav Fomichev
2022-06-03 21:30   ` Andrii Nakryiko
2022-06-01 19:02 ` [PATCH bpf-next v8 08/11] libbpf: implement bpf_prog_query_opts Stanislav Fomichev
2022-06-03 21:34   ` Andrii Nakryiko
2022-06-03 23:13     ` Stanislav Fomichev
2022-06-01 19:02 ` [PATCH bpf-next v8 09/11] bpftool: implement cgroup tree for BPF_LSM_CGROUP Stanislav Fomichev
2022-06-01 19:02 ` [PATCH bpf-next v8 10/11] selftests/bpf: lsm_cgroup functional test Stanislav Fomichev
2022-06-01 19:02 ` [PATCH bpf-next v8 11/11] selftests/bpf: verify lsm_cgroup struct sock access Stanislav Fomichev
2022-06-03  1:52   ` Martin KaFai Lau
2022-06-03  1:59     ` Stanislav Fomichev
2022-06-03  5:38       ` Martin KaFai Lau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220607221756.ez4ntth5qnuev3ap@kafai-mbp \
    --to=kafai@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.