From: Eduard Zingerman <eddyz87@gmail.com>
To: Shung-Hsi Yu <shung-hsi.yu@suse.com>,
Paul Chaignon <paul.chaignon@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com>
Subject: Re: [PATCH v2 bpf-next 1/2] bpf: Avoid one round of bounds deduction
Date: Tue, 10 Mar 2026 12:45:39 -0700 [thread overview]
Message-ID: <cc228139101e28d2bc76beb371a2c3f89eed75f3.camel@gmail.com> (raw)
In-Reply-To: <xec3lnz6smkki57civu5z6hlr5vl6kqnec7f7zxza4vifs2qf7@g4o6gxqmcnlz>
On Tue, 2026-03-10 at 15:56 +0800, Shung-Hsi Yu wrote:
[...]
> Agree that perhaps we still need to keep 3 rounds of deduction after
> poking at this further.
>
> I tried to run an updated cbmc script[a], manually editing the file to
> change the number of __reg_deduce_bounds calls made, and check whether
> an extra call would further change reg_state. For
> __reg_deduce_bounds_old, it needs 3 calls to pass verification, and for
> __reg_deduce_bounds_new, it still needs 3.
Using the same logic I played with orderings a bit:
- For new ordering 3 and 4 deduction rounds are proven to be identical.
- For ordering in [1] 2 and 3 deduction rounds are proven to be identical,
1 round is not enough.
So, I think [2] is the way to go:
static void __reg_deduce_bounds(struct bpf_reg_state *reg)
{
deduce_bounds_64_from_64(reg);
deduce_bounds_32_from_64(reg);
deduce_bounds_32_from_32(reg);
deduce_bounds_64_from_32(reg);
}
With __reg_deduce_bounds() done 2 times.
[1] https://github.com/eddyz87/deduce-bounds-verif/blob/76755f763f9282b74ca4e2251f83767502a98e5e/deduce_bounds_new.c#L321
[2] https://github.com/eddyz87/bpf/tree/deduce-bounds-reshuffle
[...]
next prev parent reply other threads:[~2026-03-10 19:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 0:01 [PATCH v2 bpf-next 1/2] bpf: Avoid one round of bounds deduction Paul Chaignon
2026-03-07 0:03 ` [PATCH v2 bpf-next 2/2] selftests/bpf: Test case for refinement improvement using 64b bounds Paul Chaignon
2026-03-10 1:07 ` [PATCH v2 bpf-next 1/2] bpf: Avoid one round of bounds deduction Eduard Zingerman
2026-03-10 1:30 ` Eduard Zingerman
2026-03-10 5:53 ` Eduard Zingerman
2026-03-10 7:56 ` Shung-Hsi Yu
2026-03-10 19:45 ` Eduard Zingerman [this message]
2026-03-12 18:35 ` Paul Chaignon
2026-03-13 2:17 ` Shung-Hsi Yu
2026-03-13 4:54 ` Eduard Zingerman
2026-03-17 5:52 ` Shung-Hsi Yu
2026-03-13 10:45 ` Paul Chaignon
2026-03-17 6:03 ` Shung-Hsi Yu
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=cc228139101e28d2bc76beb371a2c3f89eed75f3.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=harishankar.vishwanathan@gmail.com \
--cc=paul.chaignon@gmail.com \
--cc=shung-hsi.yu@suse.com \
/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.