On Fri, 6 Dec 2024 at 19:26, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Dec 6, 2024 at 9:42 AM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > Or, *importantly*, if user anticipates that "freplace-ment" BPF > > program for such subprog might need to invalidate packet pointers, but > > the default subprog implementation doesn't actually call any of those > > special helpers, user can just explicitly say that "yes, this subprog > > should be treated as such that invalidates pkt pointers". With your > > approach there is no way to even express this, unless you hack default > > subprog implementation to intentionally have reachable > > pkt-invalidating helper, but not really call it at runtime. > > Exactly. > This artificial issue can be easily solved without tags. > The nop subprog can have an empty call to bpf_skb_pull_data(skb, 0). > And it will be much more obvious to anyone reading the C code > instead of a magic tag. Wouldn't it be less obvious? You would still need a fat comment explaining why you're doing a dummy bpf_skb_pull_data, because normally it wouldn't occur if it is to clear pkt pointers, and you will say it's because it tells the verifier that it invalidates the packet for the caller. It would certainly be clear if we had a bpf_skb_clear_pkt_ptrs, which would be a verifier built-in and no-op at runtime, but we don't. But then that's the same as a tag. > > > No, it's not. It's conceptually absolutely the same. Verifier can > > derive that global subprog arg has to be a trusted pointer. It's just > > that with pkt invalidation it's trivial enough to detect (crudely and > > eagerly, but still) in check_cfg(), while for trusted pointers you > > can't take this shortcut. > > Not really. We only introduced the following tags: > __arg_ctx > __arg_trusted > __arg_arena > because the verifier cannot infer them. > We are _not_ going to introduce __arg_dynptr as we argued in the past. > Anything that can be expressed via normal C should stay in C.
