[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADxym3a357bCbUgMgocv2ywHb9ZKEmNT3j3ico7AXWZD3r99kQ@mail.gmail.com>
Date: Wed, 13 Dec 2023 10:11:37 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: andrii@...nel.org, yonghong.song@...ux.dev, ast@...nel.org,
daniel@...earbox.net, john.fastabend@...il.com,
martin.lau@...ux.dev, song@...nel.org, kpsingh@...nel.org,
sdf@...gle.com, haoluo@...gle.com, jolsa@...nel.org,
bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/2] bpf: make the verifier trace the "not
qeual" for regs
On Wed, Dec 13, 2023 at 7:23 AM Eduard Zingerman <eddyz87@...il.com> wrote:
>
> On Tue, 2023-12-12 at 21:10 +0800, Menglong Dong wrote:
> > We can derive some new information for BPF_JNE in regs_refine_cond_op().
> > Take following code for example:
> >
> > /* The type of "a" is u16 */
> > if (a > 0 && a < 100) {
> > /* the range of the register for a is [0, 99], not [1, 99],
> > * and will cause the following error:
> > *
> > * invalid zero-sized read
> > *
> > * as a can be 0.
> > */
> > bpf_skb_store_bytes(skb, xx, xx, a, 0);
> > }
> >
> > In the code above, "a > 0" will be compiled to "jmp xxx if a == 0". In the
> > TRUE branch, the dst_reg will be marked as known to 0. However, in the
> > fallthrough(FALSE) branch, the dst_reg will not be handled, which makes
> > the [min, max] for a is [0, 99], not [1, 99].
> >
> > For BPF_JNE, we can reduce the range of the dst reg if the src reg is a
> > const and is exactly the edge of the dst reg.
> >
> > Signed-off-by: Menglong Dong <menglong8.dong@...il.com>
> > ---
>
> Acked-by: Eduard Zingerman <eddyz87@...il.com>
>
> > kernel/bpf/verifier.c | 29 ++++++++++++++++++++++++++++-
> > 1 file changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 727a59e4a647..08ee0e02df96 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -14332,7 +14332,34 @@ static void regs_refine_cond_op(struct bpf_reg_state *reg1, struct bpf_reg_state
> > }
> > break;
> > case BPF_JNE:
> > - /* we don't derive any new information for inequality yet */
> > + if (!is_reg_const(reg2, is_jmp32))
> > + swap(reg1, reg2);
> > + if (!is_reg_const(reg2, is_jmp32))
> > + break;
> > +
> > + /* try to recompute the bound of reg1 if reg2 is a const and
> > + * is exactly the edge of reg1.
> > + */
> > + val = reg_const_value(reg2, is_jmp32);
> > + if (is_jmp32) {
> > + if (reg1->u32_min_value == (u32)val)
> > + reg1->u32_min_value++;
>
> Nit: I spent an unreasonable amount of time trying to figure out if
> overflow might be an issue here. Would it be helpful to add a
> comment like below? (not sure, maybe it's obvious and I'm being slow)
>
> /* u32_min_value is not equal to 0xffffffff at this point,
> * because otherwise u32_max_value is 0xffffffff as well,
> * in such a case both reg1 and reg2 would be constants,
> * jump would be predicted and reg_set_min_max() won't
> * be called.
> * Same reasoning works for all {u,s}{min,max}{32,64} cases below.
> */
Okay, I'll add this comment in the next version.
Thanks!
Menglong Dong
Powered by blists - more mailing lists