From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
Cc: Paul Chaignon <paul.chaignon@gmail.com>,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>,
Srinivas Narayana <srinivas.narayana@rutgers.edu>,
Santosh Nagarakatte <santosh.nagarakatte@rutgers.edu>
Subject: Re: [PATCH v2 bpf-next 4/6] bpf: Simulate branches to prune based on range violations
Date: Wed, 25 Mar 2026 13:52:19 +0000 [thread overview]
Message-ID: <87tsu4hv8s.fsf@gmail.com> (raw)
In-Reply-To: <CAM=Ch066+XPxFJTN-QSFLBC0fgfpnvvEfkrGnjsdeTgfTzpWLw@mail.gmail.com>
Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com> writes:
> On Mon, Mar 23, 2026 at 12:19 PM Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
>>
>> Paul Chaignon <paul.chaignon@gmail.com> writes:
>>
>> > From: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
>> >
> [...]
>> > +static void regs_refine_cond_op(struct bpf_reg_state *reg1, struct bpf_reg_state *reg2,
>> > + u8 opcode, bool is_jmp32);
>> > +static u8 rev_opcode(u8 opcode);
>> > +
>> > +/* Learn more information about live branches by simulating both branches being
>> > + * taken using regs_refine_cond_op. Because regs_refine_cond_op is sound when
>> > + * the branch is taken, if it produces ill-formed register bounds, it must mean
>> > + * that the branch is dead.
>> > + */
>> Sorry for being nit-picky, could you please use kernel style comment style +
>
> Thanks for the suggestion. To clarify, by kernel-style did you mean
> keeping the beginning line empty?
> Or something else that I might have missed.
Yes, first line just /*, then text goes next line.
>
>> maybe reword it a little bit, instead of:
>>
>> /*
>> * Because regs_refine_cond_op is sound when
>> * the branch is taken, if it produces ill-formed register bounds, it must mean
>> * that the branch is dead.
>> */
>> Something like:
>> /*
>> * regs_refine_cond_op() is sound, so producing ill-formed register
>> * bounds for the branch means that branch is dead.
>> */
>>
> This sounds good.
>
>> > +static int simulate_both_branches_taken(struct bpf_verifier_env *env, u8 opcode, bool is_jmp32)
>> > +{
>> > + /* Fallthrough (FALSE) branch */
>> > + regs_refine_cond_op(&env->false_reg1, &env->false_reg2, rev_opcode(opcode), is_jmp32);
>> > + reg_bounds_sync(&env->false_reg1);
>> > + reg_bounds_sync(&env->false_reg2);
>> This is probably more related to patch 2: is it necessary to have both
>> true/false_reg1/2 pairs, it looks like we process false branch before
>> the true branch and they never intersect, don't they? So it worth
>> removing a pair of bpf_reg_states from env?
>
> We do process the false branch before the true branch in
> is_branch_taken->simulate_both_branches. But when both branches are possible
> (we return -1), we need all the four env buffers to hold the updated results
> of both branch simulations simultaneously.
>
> The new verifier state for other_branch hasn't been created at the time
> simulate_both_branches is called, so we cannot copy the results to their
> final destinations immediately. We must hold them in the buffers until
> after push_stack,
> after which we can copy them back into their corresponding register states:
>
> copy_register_state(dst_reg, &env->false_reg1);
> copy_register_state(src_reg, &env->false_reg2);
> copy_register_state(&other_branch_regs[insn->dst_reg], &env->true_reg1);
> if (BPF_SRC(insn->code) == BPF_X)
> copy_register_state(&other_branch_regs[insn->src_reg], &env->true_reg2);
>
> [...]
next prev parent reply other threads:[~2026-03-25 13:52 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 16:45 [PATCH v2 bpf-next 0/6] Fix invariant violations and improve branch detection Paul Chaignon
2026-03-20 16:47 ` [PATCH v2 bpf-next 1/6] bpf: Refactor reg_bounds_sanity_check Paul Chaignon
2026-03-23 8:01 ` Shung-Hsi Yu
2026-03-23 14:16 ` Mykyta Yatsenko
2026-03-24 16:56 ` Harishankar Vishwanathan
2026-03-24 18:16 ` Mykyta Yatsenko
2026-03-20 16:49 ` [PATCH v2 bpf-next 2/6] bpf: Use bpf_verifier_env buffers for reg_set_min_max Paul Chaignon
2026-03-23 8:15 ` Shung-Hsi Yu
2026-03-23 15:33 ` Mykyta Yatsenko
2026-03-23 18:42 ` Eduard Zingerman
2026-03-30 12:05 ` Paul Chaignon
2026-03-31 1:51 ` Eduard Zingerman
2026-03-31 14:56 ` Paul Chaignon
2026-03-31 14:28 ` KaFai Wan
2026-04-01 11:15 ` Paul Chaignon
2026-03-20 16:49 ` [PATCH v2 bpf-next 3/6] bpf: Exit early if reg_bounds_sync gets invalid inputs Paul Chaignon
2026-03-23 12:12 ` Shung-Hsi Yu
2026-03-24 17:46 ` Harishankar Vishwanathan
2026-03-23 18:47 ` Eduard Zingerman
2026-03-24 19:28 ` Harishankar Vishwanathan
2026-03-24 19:33 ` Eduard Zingerman
2026-04-01 12:21 ` Paul Chaignon
2026-04-01 19:36 ` Harishankar Vishwanathan
2026-04-01 20:21 ` Eduard Zingerman
2026-04-01 21:19 ` Paul Chaignon
2026-03-20 16:49 ` [PATCH v2 bpf-next 4/6] bpf: Simulate branches to prune based on range violations Paul Chaignon
2026-03-23 12:23 ` Shung-Hsi Yu
2026-03-23 16:19 ` Mykyta Yatsenko
2026-03-24 20:36 ` Harishankar Vishwanathan
2026-03-25 13:52 ` Mykyta Yatsenko [this message]
2026-03-23 19:05 ` Eduard Zingerman
2026-03-24 23:59 ` Harishankar Vishwanathan
2026-03-25 0:08 ` Eduard Zingerman
2026-03-20 16:50 ` [PATCH v2 bpf-next 5/6] selftests/bpf: Cover invariant violation cases from syzbot Paul Chaignon
2026-03-23 17:46 ` Mykyta Yatsenko
2026-03-28 16:20 ` Paul Chaignon
2026-03-28 17:31 ` Alexei Starovoitov
2026-03-20 16:50 ` [PATCH v2 bpf-next 6/6] selftests/bpf: Remove invariant violation flags Paul Chaignon
2026-03-23 18:04 ` Mykyta Yatsenko
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=87tsu4hv8s.fsf@gmail.com \
--to=mykyta.yatsenko5@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=paul.chaignon@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.