All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Protopopov <aspsk@isovalent.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
	Shuah Khan <shuah@kernel.org>, Hou Tao <houtao1@huawei.com>,
	Joe Stringer <joe@isovalent.com>, bpf <bpf@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK"
	<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/3] bpf: consider CONST_PTR_TO_MAP as trusted pointer to struct bpf_map
Date: Wed, 19 Jul 2023 07:10:23 +0000	[thread overview]
Message-ID: <ZLeMX4cJnKeXJfqW@zh-lab-node-5> (raw)
In-Reply-To: <CAADnVQLt=k6T0s3cRZRB26D+7TXcvR5CRk-q4SbKK6FQKuyjhg@mail.gmail.com>

On Tue, Jul 18, 2023 at 05:54:27PM -0700, Alexei Starovoitov wrote:
> On Sun, Jul 16, 2023 at 12:49 AM Anton Protopopov <aspsk@isovalent.com> wrote:
> >
> > On Fri, Jul 14, 2023 at 10:56:00AM -0700, Alexei Starovoitov wrote:
> > > On Fri, Jul 14, 2023 at 7:20 AM Anton Protopopov <aspsk@isovalent.com> wrote:
> > > >
> > > > Patch verifier to regard values of type CONST_PTR_TO_MAP as trusted
> > > > pointers to struct bpf_map. This allows kfuncs to work with `struct
> > > > bpf_map *` arguments.
> > > >
> > > > Save some bytes by defining btf_bpf_map_id as BTF_ID_LIST_GLOBAL_SINGLE
> > > > (which is u32[1]), not as BTF_ID_LIST (which is u32[64]).
> > > >
> > > > Signed-off-by: Anton Protopopov <aspsk@isovalent.com>
> > > > ---
> > > >  include/linux/btf_ids.h | 1 +
> > > >  kernel/bpf/map_iter.c   | 3 +--
> > > >  kernel/bpf/verifier.c   | 5 ++++-
> > > >  3 files changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> > > > index 00950cc03bff..a3462a9b8e18 100644
> > > > --- a/include/linux/btf_ids.h
> > > > +++ b/include/linux/btf_ids.h
> > > > @@ -267,5 +267,6 @@ MAX_BTF_TRACING_TYPE,
> > > >  extern u32 btf_tracing_ids[];
> > > >  extern u32 bpf_cgroup_btf_id[];
> > > >  extern u32 bpf_local_storage_map_btf_id[];
> > > > +extern u32 btf_bpf_map_id[];
> > > >
> > > >  #endif
> > > > diff --git a/kernel/bpf/map_iter.c b/kernel/bpf/map_iter.c
> > > > index d06d3b7150e5..b67996147895 100644
> > > > --- a/kernel/bpf/map_iter.c
> > > > +++ b/kernel/bpf/map_iter.c
> > > > @@ -78,8 +78,7 @@ static const struct seq_operations bpf_map_seq_ops = {
> > > >         .show   = bpf_map_seq_show,
> > > >  };
> > > >
> > > > -BTF_ID_LIST(btf_bpf_map_id)
> > > > -BTF_ID(struct, bpf_map)
> > > > +BTF_ID_LIST_GLOBAL_SINGLE(btf_bpf_map_id, struct, bpf_map)
> > > >
> > > >  static const struct bpf_iter_seq_info bpf_map_seq_info = {
> > > >         .seq_ops                = &bpf_map_seq_ops,
> > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > index 0b9da95331d7..5663f97ef292 100644
> > > > --- a/kernel/bpf/verifier.c
> > > > +++ b/kernel/bpf/verifier.c
> > > > @@ -5419,6 +5419,9 @@ static bool is_trusted_reg(const struct bpf_reg_state *reg)
> > > >         if (reg->ref_obj_id)
> > > >                 return true;
> > > >
> > > > +       if (reg->type == CONST_PTR_TO_MAP)
> > > > +               return true;
> > > > +
> > >
> > > Overall it looks great.
> > > Instead of above, how about the following instead:
> > >
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 0b9da95331d7..cd08167dc347 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -10775,7 +10775,7 @@ static int check_kfunc_args(struct
> > > bpf_verifier_env *env, struct bpf_kfunc_call_
> > >                         if (!is_kfunc_trusted_args(meta) && !is_kfunc_rcu(meta))
> > >                                 break;
> > >
> > > -                       if (!is_trusted_reg(reg)) {
> > > +                       if (!is_trusted_reg(reg) &&
> > > !reg2btf_ids[base_type(reg->type)]) {
> > >
> > >
> > > This way we won't need to list every convertible type in is_trusted_reg.
> > >
> > > I'm a bit hesitant to put reg2btf_ids[] check directly into is_trusted_reg().
> > > Maybe it's ok, but it needs more analysis.
> >
> > I am not sure I see a difference in adding a check you proposed above and
> > adding the reg2btf_ids[] check directly into the is_trusted_reg() function.
> > Basically, we say "if type is in reg2btf_ids[], then consider it trusted" in
> > both cases. AFAIS, currently the reg2btf_ids[] contains only trusted types,
> > however, could it happen that we add a non-trusted type there?
> >
> > So, I would leave the patch as is (which also makes sense because the
> > const-ptr-to-map is a special case), or add the "reg2btf_ids[] check"
> > directly into the is_trusted_reg() function.
> 
> Fair enough. Let's add reg2btf_ids[] to is_trusted_reg() directly.

Thanks, I will send v2.

  reply	other threads:[~2023-07-19  7:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230714141747.41560-1-aspsk@isovalent.com>
2023-07-14 14:20 ` [PATCH bpf-next 0/3] allow bpf_map_sum_elem_count for all program types Anton Protopopov
2023-07-14 14:20   ` [PATCH bpf-next 1/3] bpf: consider CONST_PTR_TO_MAP as trusted pointer to struct bpf_map Anton Protopopov
2023-07-14 17:56     ` Alexei Starovoitov
2023-07-16  7:50       ` Anton Protopopov
2023-07-19  0:54         ` Alexei Starovoitov
2023-07-19  7:10           ` Anton Protopopov [this message]
2023-07-14 14:20   ` [PATCH bpf-next 2/3] bpf: make an argument const in the bpf_map_sum_elem_count kfunc Anton Protopopov
2023-07-14 14:21   ` [PATCH bpf-next 3/3] bpf: allow any program to use " Anton Protopopov

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=ZLeMX4cJnKeXJfqW@zh-lab-node-5 \
    --to=aspsk@isovalent.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=houtao1@huawei.com \
    --cc=joe@isovalent.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=sdf@google.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yhs@fb.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.