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