From: Yonghong Song <yonghong.song@linux.dev>
To: Cupertino Miranda <cupertino.miranda@oracle.com>, bpf@vger.kernel.org
Cc: jose.marchesi@oracle.com, david.faust@oracle.com,
elena.zannoni@oracle.com, alexei.starovoitov@gmail.com
Subject: Re: [PATCH bpf-next 3/3] bpf: relax MUL range computation check
Date: Mon, 15 Apr 2024 11:38:52 -0700 [thread overview]
Message-ID: <154c5a8c-181c-4922-b1f8-a772b831fca3@linux.dev> (raw)
In-Reply-To: <20240411173732.221881-3-cupertino.miranda@oracle.com>
On 4/11/24 10:37 AM, Cupertino Miranda wrote:
> MUL instruction required that src_reg would be a known value (i.e.
> src_reg would be evaluate as a const value). The condition in this case
> can be relaxed, since multiplication is a commutative operator and the
> range computation is still valid if at least one of its registers is
> known.
>
> BPF self-tests were added to check the new functionality.
>
> Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
> ---
> kernel/bpf/verifier.c | 10 +-
> .../selftests/bpf/progs/verifier_bounds.c | 99 +++++++++++++++++++
> 2 files changed, 105 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7894af2e1bdb..a326ec024d82 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -13741,15 +13741,17 @@ static bool is_const_reg_and_valid(struct bpf_reg_state reg, bool alu32,
> }
>
> static bool is_safe_to_compute_dst_reg_ranges(struct bpf_insn *insn,
> + struct bpf_reg_state dst_reg,
> struct bpf_reg_state src_reg)
> {
> - bool src_known;
> + bool src_known, dst_known;
> u64 insn_bitness = (BPF_CLASS(insn->code) == BPF_ALU64) ? 64 : 32;
> bool alu32 = (BPF_CLASS(insn->code) != BPF_ALU64);
> u8 opcode = BPF_OP(insn->code);
>
> bool valid_known = true;
> src_known = is_const_reg_and_valid(src_reg, alu32, &valid_known);
> + dst_known = is_const_reg_and_valid(dst_reg, alu32, &valid_known);
Is it a possible the above could falsely reject some operation since
in the original code, dst_reg is not checked here?
>
> /* Taint dst register if offset had invalid bounds
> * derived from e.g. dead branches.
> @@ -13765,10 +13767,10 @@ static bool is_safe_to_compute_dst_reg_ranges(struct bpf_insn *insn,
> case BPF_OR:
> return true;
>
> - /* Compute range for MUL if the src_reg is known.
> + /* Compute range for MUL if at least one of its registers is know.
know => known
> */
> case BPF_MUL:
> - return src_known;
> + return src_known || dst_known;
>
> /* Shift operators range is only computable if shift dimension operand
> * is known. Also, shifts greater than 31 or 63 are undefined. This
> @@ -13799,7 +13801,7 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
> bool alu32 = (BPF_CLASS(insn->code) != BPF_ALU64);
> int ret;
>
> - if (!is_safe_to_compute_dst_reg_ranges(insn, src_reg)) {
> + if (!is_safe_to_compute_dst_reg_ranges(insn, *dst_reg, src_reg)) {
> __mark_reg_unknown(env, dst_reg);
> return 0;
> }
> diff --git a/tools/testing/selftests/bpf/progs/verifier_bounds.c b/tools/testing/selftests/bpf/progs/verifier_bounds.c
Let us break this commit into two patches: verifier change and selftest change. This will make possible backport easier.
> index 2fcf46341b30..09bb1b270ca7 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_bounds.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_bounds.c
> @@ -949,6 +949,105 @@ l1_%=: r0 = 0; \
> : __clobber_all);
> }
>
[...]
next prev parent reply other threads:[~2024-04-15 18:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 17:37 [PATCH bpf-next 1/3] bpf: fix to XOR and OR range computation Cupertino Miranda
2024-04-11 17:37 ` [PATCH bpf-next 2/3] bpf: refactor checks for " Cupertino Miranda
2024-04-15 18:25 ` Yonghong Song
2024-04-16 16:12 ` Cupertino Miranda
2024-04-11 17:37 ` [PATCH bpf-next 3/3] bpf: relax MUL range computation check Cupertino Miranda
2024-04-15 18:38 ` Yonghong Song [this message]
2024-04-16 8:57 ` Cupertino Miranda
2024-04-15 18:07 ` [PATCH bpf-next 1/3] bpf: fix to XOR and OR range computation Yonghong Song
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=154c5a8c-181c-4922-b1f8-a772b831fca3@linux.dev \
--to=yonghong.song@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=cupertino.miranda@oracle.com \
--cc=david.faust@oracle.com \
--cc=elena.zannoni@oracle.com \
--cc=jose.marchesi@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox