All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Florent Revest <revest@chromium.org>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, Yonghong Song <yhs@fb.com>,
	KP Singh <kpsingh@kernel.org>,
	Brendan Jackman <jackmanb@chromium.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/5] bpf: Add a ARG_PTR_TO_CONST_STR argument type
Date: Tue, 16 Mar 2021 18:02:42 -0700	[thread overview]
Message-ID: <CAEf4BzbiK8vTO_-rgwr43+auTsSfNuTc_zLyR9qH9Dz4NLWsXA@mail.gmail.com> (raw)
In-Reply-To: <CABRcYm+6By6_j+BaRMkw2-fnrJHKQYsoBMGkUKDXxYnm_AH88Q@mail.gmail.com>

On Tue, Mar 16, 2021 at 5:46 PM Florent Revest <revest@chromium.org> wrote:
>
> On Wed, Mar 17, 2021 at 1:35 AM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> > On Tue, Mar 16, 2021 at 4:58 PM Florent Revest <revest@chromium.org> wrote:
> > > On Tue, Mar 16, 2021 at 2:03 AM Andrii Nakryiko
> > > <andrii.nakryiko@gmail.com> wrote:
> > > > On Wed, Mar 10, 2021 at 2:02 PM Florent Revest <revest@chromium.org> wrote:
> > > > > +       } else if (arg_type == ARG_PTR_TO_CONST_STR) {
> > > > > +               struct bpf_map *map = reg->map_ptr;
> > > > > +               int map_off, i;
> > > > > +               u64 map_addr;
> > > > > +               char *map_ptr;
> > > > > +
> > > > > +               if (!map || !bpf_map_is_rdonly(map)) {
> > > > > +                       verbose(env, "R%d does not point to a readonly map'\n", regno);
> > > > > +                       return -EACCES;
> > > > > +               }
> > > > > +
> > > > > +               if (!tnum_is_const(reg->var_off)) {
> > > > > +                       verbose(env, "R%d is not a constant address'\n", regno);
> > > > > +                       return -EACCES;
> > > > > +               }
> > > > > +
> > > > > +               if (!map->ops->map_direct_value_addr) {
> > > > > +                       verbose(env, "no direct value access support for this map type\n");
> > > > > +                       return -EACCES;
> > > > > +               }
> > > > > +
> > > > > +               err = check_helper_mem_access(env, regno,
> > > > > +                                             map->value_size - reg->off,
> > > > > +                                             false, meta);
> > > >
> > > > you expect reg to be PTR_TO_MAP_VALUE, so probably better to directly
> > > > use check_map_access(). And double-check that register is of expected
> > > > type. just the presence of ref->map_ptr might not be sufficient?
> > >
> > > Sorry, just making sure I understand your comment correctly, are you
> > > suggesting that we:
> > > 1- skip the check_map_access_type() currently done by
> > > check_helper_mem_access()? or did you implicitly mean that we should
> > > call it as well next to check_map_access() ?
> >
> > check_helper_mem_access() will call check_map_access() for
> > PTR_TO_MAP_VALUE and we expect only PTR_TO_MAP_VALUE, right? So why go
> > through check_helper_mem_access() if we know we need
> > check_map_access()? Less indirection, more explicit. So I meant
> > "replace check_helper_mem_access() with check_map_access()".
>
> Mhh I suspect there's still a misunderstanding, these function names
> are really confusing ahah.
> What about check_map_access*_type*. which is also called by
> check_helper_mem_access (before check_map_access):
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/kernel/bpf/verifier.c#n4329
>
> Your message sounds like we should skip it so I was asking if that's
> what you also implicitly meant or if you missed it?

ah, you meant READ/WRITE access? ok, let's keep
check_helper_mem_access() then, never mind me

>
> > > 2- enforce (reg->type == PTR_TO_MAP_VALUE) even if currently
> > > guaranteed by compatible_reg_types, just to stay on the safe side ?
> >
> > I can't follow compatible_reg_types :( If it does, then I guess it's
> > fine without this check.
>
> It's alright, I can keep an extra check just for safety. :)

  reply	other threads:[~2021-03-17  1:08 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 22:02 [PATCH bpf-next 0/5] Add a snprintf eBPF helper Florent Revest
2021-03-10 22:02 ` [PATCH bpf-next 1/5] bpf: Add a ARG_PTR_TO_CONST_STR argument type Florent Revest
2021-03-11  0:04   ` kernel test robot
2021-03-11  0:04     ` kernel test robot
2021-03-11  1:00   ` kernel test robot
2021-03-11  1:00     ` kernel test robot
2021-03-16  1:03   ` Andrii Nakryiko
2021-03-16 23:58     ` Florent Revest
2021-03-17  0:35       ` Andrii Nakryiko
2021-03-17  0:45         ` Florent Revest
2021-03-17  1:02           ` Andrii Nakryiko [this message]
2021-03-17 10:32             ` Florent Revest
2021-03-10 22:02 ` [PATCH bpf-next 2/5] bpf: Add a bpf_snprintf helper Florent Revest
2021-03-11  0:14   ` kernel test robot
2021-03-11  0:14     ` kernel test robot
2021-03-11  3:12   ` kernel test robot
2021-03-11  3:12     ` kernel test robot
2021-03-11  3:12   ` [RFC PATCH] bpf: check_bpf_snprintf_call() can be static kernel test robot
2021-03-11  3:12     ` kernel test robot
2021-03-16  1:25   ` [PATCH bpf-next 2/5] bpf: Add a bpf_snprintf helper Andrii Nakryiko
2021-03-16 13:18     ` Florent Revest
2021-03-23  3:21   ` Alexei Starovoitov
2021-03-23 14:04     ` Florent Revest
2021-03-10 22:02 ` [PATCH bpf-next 3/5] libbpf: Initialize the bpf_seq_printf parameters array field by field Florent Revest
2021-03-16  4:36   ` Andrii Nakryiko
2021-03-16  4:41     ` Andrii Nakryiko
2021-03-16 22:43     ` Florent Revest
2021-03-16 23:06       ` Andrii Nakryiko
2021-03-10 22:02 ` [PATCH bpf-next 4/5] libbpf: Introduce a BPF_SNPRINTF helper macro Florent Revest
2021-03-16  4:39   ` Andrii Nakryiko
2021-03-10 22:02 ` [PATCH bpf-next 5/5] selftests/bpf: Add a series of tests for bpf_snprintf Florent Revest
2021-03-16  4:49   ` Andrii Nakryiko

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=CAEf4BzbiK8vTO_-rgwr43+auTsSfNuTc_zLyR9qH9Dz4NLWsXA@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jackmanb@chromium.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=revest@chromium.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.