From: Paul Chaignon <paul.chaignon@gmail.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>,
Srinivas Narayana <srinivas.narayana@rutgers.edu>,
Santosh Nagarakatte <santosh.nagarakatte@rutgers.edu>
Subject: Re: [PATCH bpf-next 2/4] bpf: Simulate branches to prune based on range violations
Date: Thu, 19 Mar 2026 01:13:31 +0100 [thread overview]
Message-ID: <abs_q7hZf_7vYJDL@mail.gmail.com> (raw)
In-Reply-To: <7a9255803fdfef52d86c257ccb00d3b1d37de5cc.camel@gmail.com>
On Mon, Mar 16, 2026 at 10:09:07AM -0700, Eduard Zingerman wrote:
> On Sat, 2026-03-14 at 01:01 -0400, Harishankar Vishwanathan wrote:
>
> [...]
>
> > > > + /* Fallthrough (FALSE) branch */
> > > > + regs_refine_cond_op(&false_reg1_c, &false_reg2_c, rev_opcode(opcode), is_jmp32);
> > > > + /* If there is a range bounds violation in *any* of the abstract values in either
> > > > + * reg_states in the FALSE branch (i.e. false_reg1, false_reg2), the FALSE branch must be
> > > > + * dead. Only TRUE branch will be taken.
> > > > + */
> > > > + if (range_bounds_violation(&false_reg1_c) || range_bounds_violation(&false_reg2_c))
> > > > + return 1;
> > >
> > > How hard would it be to modify reg_bounds_sync() such that it
> > > preserves invariant violation? Thus avoiding the first round of
> > > range_bounds_violation() checks.
> >
> > We can exit early in reg_bounds_sync by detecting ill-formed inputs
> > (using reg_bounds_violation itself), and have reg_bounds_sync preserve
> > the invalid bounds.
> > Unsure if preserving invalid inputs is a good idea for
> > reg_bounds_sync. Or if we should be
> > calling __mark_reg_unbounded on invalid inputs.
>
> Agree, early exit is a good option.
Thanks for the review!
We're preparing a v2 with this change and the temporary registers inside
bpf_verifier_env.
next prev parent reply other threads:[~2026-03-19 0:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 22:53 [PATCH bpf-next 0/4] Fix invariant violations and improve branch detection Paul Chaignon
2026-03-13 22:54 ` [PATCH bpf-next 1/4] bpf: Refactor reg_bounds_sanity_check Paul Chaignon
2026-03-13 22:54 ` [PATCH bpf-next 2/4] bpf: Simulate branches to prune based on range violations Paul Chaignon
2026-03-13 23:35 ` bot+bpf-ci
2026-03-14 0:05 ` Eduard Zingerman
2026-03-14 5:01 ` Harishankar Vishwanathan
2026-03-16 17:09 ` Eduard Zingerman
2026-03-19 0:13 ` Paul Chaignon [this message]
2026-03-17 6:14 ` Shung-Hsi Yu
2026-03-18 23:50 ` Paul Chaignon
2026-03-19 7:09 ` Shung-Hsi Yu
2026-03-19 17:13 ` Paul Chaignon
2026-03-19 17:17 ` Paul Chaignon
2026-03-20 5:49 ` Shung-Hsi Yu
2026-03-13 22:55 ` [PATCH bpf-next 3/4] selftests/bpf: Cover invariant violation cases from syzbot Paul Chaignon
2026-03-13 23:35 ` bot+bpf-ci
2026-03-13 22:55 ` [PATCH bpf-next 4/4] selftests/bpf: Remove invariant violation flags Paul Chaignon
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=abs_q7hZf_7vYJDL@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=harishankar.vishwanathan@gmail.com \
--cc=santosh.nagarakatte@rutgers.edu \
--cc=shung-hsi.yu@suse.com \
--cc=srinivas.narayana@rutgers.edu \
/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.