BPF List
 help / color / mirror / Atom feed
From: Shung-Hsi Yu <shung-hsi.yu@suse.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
	bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	martin.lau@kernel.org, kernel-team@meta.com,
	Eduard Zingerman <eddyz87@gmail.com>
Subject: Re: [PATCH v2 bpf-next 03/10] bpf: enforce exact retval range on subprog/callback exit
Date: Thu, 30 Nov 2023 13:23:39 +0800	[thread overview]
Message-ID: <ZWgcW2RCDW9hoOVI@u94a> (raw)
In-Reply-To: <CAEf4BzbUjsW0JfMwZQQYETafs=6yD=cs23W_PJ6=H90YMZudyQ@mail.gmail.com>

On Wed, Nov 29, 2023 at 08:23:38AM -0800, Andrii Nakryiko wrote:
> On Wed, Nov 29, 2023 at 2:56 AM Shung-Hsi Yu <shung-hsi.yu@suse.com> wrote:
> > On Tue, Nov 28, 2023 at 04:36:13PM -0800, Andrii Nakryiko wrote:
> > > Instead of relying on potentially imprecise tnum representation of
> > > expected return value range for callbacks and subprogs, validate that
> > > umin/umax range satisfy exact expected range of return values.
> > >
> > > E.g., if callback would need to return [0, 2] range, tnum can't
> > > represent this precisely and instead will allow [0, 3] range. By
> > > checking umin/umax range, we can make sure that subprog/callback indeed
> > > returns only valid [0, 2] range.
> > >
> > > Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> > > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> > > ---
> > >  include/linux/bpf_verifier.h |  7 ++++++-
> > >  kernel/bpf/verifier.c        | 40 ++++++++++++++++++++++++++----------
> > >  2 files changed, 35 insertions(+), 12 deletions(-)
> >
> > ...
> >
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -9560,6 +9565,19 @@ static bool in_rbtree_lock_required_cb(struct bpf_verifier_env *env)
> > >       return is_rbtree_lock_required_kfunc(kfunc_btf_id);
> > >  }
> > >
> > > +static bool retval_range_within(struct bpf_retval_range range, const struct bpf_reg_state *reg)
> > > +{
> > > +     return range.minval <= reg->umin_value && reg->umax_value <= range.maxval;
> > > +}
> > > +
> > > +static struct tnum retval_range_as_tnum(struct bpf_retval_range range)
> > > +{
> > > +     if (range.minval == range.maxval)
> > > +             return tnum_const(range.minval);
> > > +     else
> > > +             return tnum_range(range.minval, range.maxval);
> > > +}
> >
> > Nit: find it slightly strange to have retval_range_as_tnum() added here
> > (patch 3), only to be removed again in the patch 5. As far as I can see
> > patch 4 doesn't require this, and it is only used once.
> >
> > Perhaps just replace its use below with tnum_range() instead? (Not
> > pretty, but will be removed anyway).
> 
> I do this to delay the refactoring of verbose_invalid_scalar() which
> is used by another piece of logic which I refactor in a separate
> patch. If I don't do this temporary retval_range_as_tnum() helper, I
> might need to update some more tests that expect exact var_off value
> in logs, and I didn't want to do it. Given it's a trivial helper, it
> feels like it's not a big deal to keep it for a patch or two before
> completing the refactoring.

Replace retval_range_as_tnum(callee->callback_ret_range) with 

  tnum_range(callee->callback_ret_range.minval,
             callee->callback_ret_range.maxval)

and the verbose_invalid_scalar() signature stays the same; also no var_off
changes because it is just manual inline of retval_range_as_tnum(), as
tnum_range(n, n) == tnum_const(n).

Agree it really is not a big deal, so I won't insist on it.

> > > @@ -9597,7 +9612,10 @@ static int prepare_func_exit(struct bpf_verifier_env *env, int *insn_idx)
> > >               if (err)
> > >                       return err;
> > >
> > > -             if (!tnum_in(range, r0->var_off)) {
> > > +             /* enforce R0 return value range */
> > > +             if (!retval_range_within(callee->callback_ret_range, r0)) {
> > > +                     struct tnum range = retval_range_as_tnum(callee->callback_ret_range);

  reply	other threads:[~2023-11-30  5:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29  0:36 [PATCH v2 bpf-next 00/10] BPF verifier retval logic fixes Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 01/10] bpf: provide correct register name for exception callback retval check Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 02/10] bpf: enforce precision of R0 on callback return Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 03/10] bpf: enforce exact retval range on subprog/callback exit Andrii Nakryiko
2023-11-29  3:40   ` Andrii Nakryiko
2023-11-29 10:55   ` Shung-Hsi Yu
2023-11-29 16:23     ` Andrii Nakryiko
2023-11-30  5:23       ` Shung-Hsi Yu [this message]
2023-11-30  6:41         ` Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 04/10] selftests/bpf: add selftest validating callback result is enforced Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 05/10] bpf: enforce precise retval range on program exit Andrii Nakryiko
2023-11-29 11:23   ` Shung-Hsi Yu
2023-11-29 16:23     ` Andrii Nakryiko
2023-11-30  5:29       ` Shung-Hsi Yu
2023-11-29  0:36 ` [PATCH v2 bpf-next 06/10] bpf: unify async callback and program retval checks Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 07/10] bpf: enforce precision of R0 on program/async callback return Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 08/10] selftests/bpf: validate async callback return value check correctness Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 09/10] selftests/bpf: adjust global_func15 test to validate prog exit precision Andrii Nakryiko
2023-11-29  0:36 ` [PATCH v2 bpf-next 10/10] bpf: simplify tnum output if a fully known constant Andrii Nakryiko
2023-11-29 11:27 ` [PATCH v2 bpf-next 00/10] BPF verifier retval logic fixes Shung-Hsi Yu
2023-11-29 16:23   ` 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=ZWgcW2RCDW9hoOVI@u94a \
    --to=shung-hsi.yu@suse.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=martin.lau@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox