RE: [PATCH] bpf/arm64: support packet data load instructions

[Marat Khalili <marat.khalili@huawei.com>]

> > Handling immediate as unsigned is questionable, especially in the
> > BPF_IND case
> > it may produce incorrect results.
> 
> In Classic BPF (cBPF), when the immediate "k" is negative (when cast to signed integer), it is used
> for getting packet metadata (e.g. SKF_AD_VLAN_TAG gets the VLAN ID); otherwise it is considered
> unsigned.

Yes. Since we don't support it, we should probably consider these offsets invalid.

And in the BPF_IND case one might be tempted to load end of some packet area in
the register and use negative offsets, we probably should handle it correctly.

> > To make things worse, `__rte_pktmbuf_read` is also buggy when passed
> > very large
> > lengths (again, technically not ARM eBPF fault).
> 
> Are you referring to the potential integer wraparound in the off+len > rte_pktmbuf_pkt_len(m)
> comparison?
> [BZ1724]
> Or some other bug in __rte_pktmbuf_read()?
> 
> [BZ1724]: https://bugs.dpdk.org/show_bug.cgi?id=1724

Technically that one manifested itself in rte_pktmbuf_read (without
underscores), but essentially the root cause is the same. In the eBPF BPF_ABS
case we could potentially rely on `__rte_pktmbuf_read` for refusing to accept
negative values converted to large integers, but due to overflows we cannot.