All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cupertino Miranda <cupertino.miranda@oracle.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: bpf@vger.kernel.org, Yonghong Song <yonghong.song@linux.dev>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	David Faust <david.faust@oracle.com>,
	"Elena Zannoni" <elena.zannoni@oracle.com>
Subject: Re: [PATCH bpf-next v2 1/5] bpf/verifier: refactor checks for range computation
Date: Fri, 19 Apr 2024 10:37:29 +0100	[thread overview]
Message-ID: <878r19k812.fsf@oracle.com> (raw)
In-Reply-To: <f347d6ea9a0d8ecb77fe13a89470195735c706d2.camel@gmail.com>


Eduard Zingerman writes:

> On Wed, 2024-04-17 at 13:23 +0100, Cupertino Miranda wrote:
> [...]
>
>> @@ -13406,53 +13490,19 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
>
> [...]
>
>> -	if (!src_known &&
>> -	    opcode != BPF_ADD && opcode != BPF_SUB && opcode != BPF_AND) {
>> +	int is_safe = is_safe_to_compute_dst_reg_range(insn, src_reg);
>> +	switch (is_safe) {
>> +	case UNCOMPUTABLE_RANGE:
>>  		__mark_reg_unknown(env, dst_reg);
>>  		return 0;
>> +	case UNDEFINED_BEHAVIOUR:
>> +		mark_reg_unknown(env, regs, insn->dst_reg);
>> +		return 0;
>> +	default:
>> +		break;
>>  	}
>
> Nit: I know that the division between __mark_reg_unknown() and
> mark_reg_unknown() was asked for directly, but tbh I don't think that
> it adds any value here, here is how mark_reg_unknown() is implemented:
>
> static void mark_reg_unknown(struct bpf_verifier_env *env,
> 			     struct bpf_reg_state *regs, u32 regno)
> {
> 	if (WARN_ON(regno >= MAX_BPF_REG)) {
> 		... mark all regs not init ...
> 		return;
>     }
> 	__mark_reg_unknown(env, regs + regno);
> }
>
> The 'regno >= MAX_BPF_REG' does not apply here, because
> adjust_scalar_min_max_vals() is only called from the following stack:
> - check_alu_op
>   - adjust_reg_min_max_vals
>     - adjust_scalar_min_max_vals
>
> The check_alu_op() does check_reg_arg() which verifies that both src
> and dst register numbers are within bounds.
>
> I suggest to replace the enum with as boolean value.
> Miranda, Yonhong, what do you think?

Thanks for the detailed review.

Well, honestly I could not evaluate if there was any actual difference
between the approaches. Although I can understand range computation in
isolation of an instruction I still did not explore the code in the
global perspective, for example the handling of control-flow.
I was proud of the initial boolean implementation that was very clean
and simple, although like Yonghong said, not truly a refactor.
If everyone agrees that it is Ok, I will be happy to change it back.

>
> [...]

  reply	other threads:[~2024-04-19  9:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 12:23 [PATCH bpf-next v2 0/5] bpf/verifier: range computation improvements Cupertino Miranda
2024-04-17 12:23 ` [PATCH bpf-next v2 1/5] bpf/verifier: refactor checks for range computation Cupertino Miranda
2024-04-18 22:37   ` Eduard Zingerman
2024-04-19  9:37     ` Cupertino Miranda [this message]
2024-04-19 17:38       ` Eduard Zingerman
2024-04-23 19:28         ` Eduard Zingerman
2024-04-23 19:36           ` Cupertino Miranda
2024-04-23 19:37             ` Eduard Zingerman
2024-04-17 12:23 ` [PATCH bpf-next v2 2/5] bpf/verifier: improve XOR and OR " Cupertino Miranda
2024-04-18 23:57   ` Eduard Zingerman
2024-04-17 12:23 ` [PATCH bpf-next v2 3/5] selftests/bpf: XOR and OR range computation tests Cupertino Miranda
2024-04-19  1:24   ` Eduard Zingerman
2024-04-19  9:41     ` Cupertino Miranda
2024-04-23 20:33   ` Yonghong Song
2024-04-17 12:23 ` [PATCH bpf-next v2 4/5] bpf/verifier: relax MUL range computation check Cupertino Miranda
2024-04-19  2:30   ` Eduard Zingerman
2024-04-19  9:47     ` Cupertino Miranda
2024-04-23 20:53       ` Yonghong Song
2024-04-24 14:59         ` Cupertino Miranda
2024-04-17 12:23 ` [PATCH bpf-next v2 5/5] selftests/bpf: MUL range computation tests Cupertino Miranda
2024-04-19  2:32   ` 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=878r19k812.fsf@oracle.com \
    --to=cupertino.miranda@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=david.faust@oracle.com \
    --cc=eddyz87@gmail.com \
    --cc=elena.zannoni@oracle.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.