Re: [PATCH v3 bpf-next 1/2] bpf: Relax precision marking in open coded iters and may_goto loop.

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2024-05-28 at 20:22 -0700, Alexei Starovoitov wrote:

[...]

> 

> > However, below is an example where if comparison is BPF_X.
> > Note that I obfuscated constant 5 as a volatile variable.
> > And here is what happens when verifier rejects the program:
> 
> Sounds pretty much like: doctor it hurts when I do that.

Well, the point is not in the volatile variable but in the BPF_X
comparison instruction. The bound might a size of some buffer,
e.g. encoded like this:

struct foo {
  int *items;
  int max_items; // suppose this is 5 for some verification path
};               // and 7 for another.

And you don't need bpf_for specifically, an outer loop with
can_loop should also lead to get_loop_entry(...) being non-NULL.

> > +      volatile unsigned long five = 5;
> > +      unsigned long sum = 0, i = 0;
> > +      struct bpf_iter_num it;
> > +      int *v;
> > +
> > +      bpf_iter_num_new(&it, 0, 10);
> > +      while ((v = bpf_iter_num_next(&it))) {
> > +              if (i < five)
> > +                      sum += arr[i++];
> 
> If you're saying that the verifier should accept that
> no matter what then I have to disagree.
> Not interested in avoiding issues in programs that
> are actively looking to explore a verifier implementation detail.

I don't think that this is a very exotic pattern,
such code could be written if one has a buffer with a dynamic bound
and seeks to fill it with items from some collection applying filtering.

I do not insist that varifier should accept such programs,
but since we are going for heuristics to do the widening,
I think we should try and figure out a few examples when
heuristics breaks, just to understand if that is ok.