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

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Marat Khalili [mailto:marat.khalili@huawei.com]
> Sent: Wednesday, 18 March 2026 14.07
> 
> > > 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.

+1

> 
> 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.

In Classic BPF, negative "k" has special meaning for both BPF_ABS and BPF_IND.
So we should consider it invalid for both cases.

That prevents applications from using it the way you describe.
And it will allow us to add BPF library support for Linux-compatible special meanings later, without breaking the ABI.

> 
> > > 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.

Agree.

The off+len wraparound in rte_pktmbuf_read() and __rte_pktmbuf_read() is clearly a bug, and not intentional.
Reading the function documentation supports the conclusion that the wraparound is a bug; the off and len parameters are unsigned, and the documentation says nothing about an ability to make them behave as signed.