All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Chaignon <paul.chaignon@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Shung-Hsi Yu <shung-hsi.yu@suse.com>
Subject: Re: [PATCH bpf-next v2 3/4] selftests/bpf: Test cross-sign 64bits range refinement
Date: Fri, 25 Jul 2025 00:01:44 +0200	[thread overview]
Message-ID: <aIKtSK9LjQXB8FLY@mail.gmail.com> (raw)
In-Reply-To: <905853bfc266a6969953b4de8433ef9ca7e7a34c.camel@gmail.com>

On Thu, Jul 24, 2025 at 12:15:53PM -0700, Eduard Zingerman wrote:
> On Thu, 2025-07-24 at 15:43 +0200, Paul Chaignon wrote:

[...]

> > +SEC("socket")
> > +__description("bounds deduction cross sign boundary, negative overlap")
> > +__success __log_level(2) __flag(BPF_F_TEST_REG_INVARIANTS)
> > +__msg("7: (1f) r0 -= r6 {{.*}} R0=scalar(smin=-655,smax=smax32=-146,umin=0xfffffffffffffd71,umax=0xffffffffffffff6e,smin32=-783,umin32=0xfffffcf1,umax32=0xffffff6e,var_off=(0xfffffffffffffc00; 0x3ff))")
> 
> Interesting, note the difference: smin=-655, smin32=-783.
> There is a code to infer s32 range from s46 range in this situation in
> __reg32_deduce_bounds(), but it looks like a third __reg_deduce_bounds
> call is needed to trigger it. E.g. the following patch removes the
> difference for me:

Hm, I can add the third __reg_deduce_bounds to the first patch in the
series. That said, we may want to rethink and optimize reg_bounds_sync
in a followup patchset. It's probably worth listing all the inferences
we have and their dependencies and see if we can reorganize the
subfunctions.

> 
>   diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>   index f0a41f1596b6..87050d17baf9 100644
>   --- a/kernel/bpf/verifier.c
>   +++ b/kernel/bpf/verifier.c
>   @@ -2686,6 +2686,7 @@ static void reg_bounds_sync(struct bpf_reg_state *reg)
>           /* We might have learned something about the sign bit. */
>           __reg_deduce_bounds(reg);
>           __reg_deduce_bounds(reg);
>   +       __reg_deduce_bounds(reg);
>           /* We might have learned some bits from the bounds. */
>           __reg_bound_offset(reg);
>           /* Intersecting with the old var_off might have improved our bounds
> 
> > +__retval(0)
> > +__naked void bounds_deduct_negative_overlap(void)
> > +{
> > +	asm volatile("			\
> > +	call %[bpf_get_prandom_u32];	\
> > +	w3 = w0;			\
> > +	w6 = (s8)w0;			\
> > +	r0 = (s8)r0;			\
> > +	if w6 >= 0xf0000000 goto l0_%=;	\
> > +	r0 += r6;			\
> > +	r6 += 400;			\
> > +	r0 -= r6;			\
> > +	if r3 < r0 goto l0_%=;		\
> > +l0_%=:	r0 = 0;				\
> > +	exit;				\
> > +"	:
> > +	: __imm(bpf_get_prandom_u32)
> > +	: __clobber_all);
> > +}
> 
> [...]

  reply	other threads:[~2025-07-24 22:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-24 13:41 [PATCH bpf-next v2 0/4] bpf: Improve 64bits bounds refinement Paul Chaignon
2025-07-24 13:42 ` [PATCH bpf-next v2 1/4] bpf: Improve bounds when s64 crosses sign boundary Paul Chaignon
2025-07-24 13:43 ` [PATCH bpf-next v2 2/4] selftests/bpf: Update reg_bound range refinement logic Paul Chaignon
2025-07-24 13:43 ` [PATCH bpf-next v2 3/4] selftests/bpf: Test cross-sign 64bits range refinement Paul Chaignon
2025-07-24 19:15   ` Eduard Zingerman
2025-07-24 22:01     ` Paul Chaignon [this message]
2025-07-24 23:52       ` Eduard Zingerman
2025-07-25  7:15         ` Eduard Zingerman
2025-07-26 10:07           ` Paul Chaignon
2025-07-27 22:01             ` Eduard Zingerman
2025-07-24 13:44 ` [PATCH bpf-next v2 4/4] selftests/bpf: Test invariants on JSLT crossing sign Paul Chaignon
2025-07-24 19:24   ` Eduard Zingerman

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=aIKtSK9LjQXB8FLY@mail.gmail.com \
    --to=paul.chaignon@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=shung-hsi.yu@suse.com \
    --cc=yonghong.song@linux.dev \
    /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.