netdev - Re: [PATCH bpf-next v2 3/7] bpf: Support pulling non-linear xdp data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250910110457.152b0460@kernel.org>
Date: Wed, 10 Sep 2025 11:04:57 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Amery Hung <ameryhung@...il.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org,
 alexei.starovoitov@...il.com, andrii@...nel.org, daniel@...earbox.net,
 stfomichev@...il.com, martin.lau@...nel.org, mohsin.bashr@...il.com,
 noren@...dia.com, dtatulea@...dia.com, saeedm@...dia.com,
 tariqt@...dia.com, mbloch@...dia.com, maciej.fijalkowski@...el.com,
 kernel-team@...a.com
Subject: Re: [PATCH bpf-next v2 3/7] bpf: Support pulling non-linear xdp
 data

On Wed, 10 Sep 2025 11:17:52 -0400 Amery Hung wrote:
> > Larger note: I wonder if we should support "shifting the buffer down"
> > if there's insufficient tailroom. XDP has rather copious headroom,
> > but tailroom may be pretty tight, and it may depend on the length of
> > the headers. So if there's not enough tailroom but there's enough
> > headroom -- should we try to memmove the existing headers?  
> 
> I think it should. If users want to reserve space for metadata, they
> can check the headroom before pulling data.
> 
> If the kfunc does not do memmove(), users are still able to do so in
> XDP programs through bpf_xdp_adjust_head() and memmove(), but it feels
> less easy to use IMO.

Actually, I don't think adjust_head() would even work. The program can
adjust head and memmove() the header, but there's no way to "punch out"
the end of the head buffer. We can only grow and shrink start of packet
and end of packet. After adjust_head + memmove in the prog buffer would
look something like:

  _ _ _ _ __________ _____ _ _ _ _      ________
   hroom |  headers | old | troom      |  frag0 |
  - - - - ---------- ----- - - - -      --------

and the program has no way to "free" the "old" to let pull grab data
from frag0 in its place...

skb pull helper can allocate a completely fresh buffer, but IDK if
drivers are ready to have the head buffer swapped under their feet.
So I think that best we can do is have the pull() helper aromatically
memmove the headers.