netdev - Re: [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP

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: <20250716142015.0b309c71@kernel.org>
Date: Wed, 16 Jul 2025 14:20:15 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Lorenzo Bianconi <lorenzo@...nel.org>
Cc: Stanislav Fomichev <stfomichev@...il.com>, Jesper Dangaard Brouer
 <hawk@...nel.org>, bpf@...r.kernel.org, netdev@...r.kernel.org, Alexei
 Starovoitov <ast@...nel.org>, Daniel Borkmann <borkmann@...earbox.net>,
 Eric Dumazet <eric.dumazet@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, sdf@...ichev.me,
 kernel-team@...udflare.com, arthur@...hurfabre.com, jakub@...udflare.com
Subject: Re: [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for
 XDP_REDIRECTed packets

On Wed, 16 Jul 2025 13:17:53 +0200 Lorenzo Bianconi wrote:
> > > I can't see what the non-redirected use-case could be. Can you please provide
> > > more details?
> > > Moreover, can it be solved without storing the rx_hash (or the other
> > > hw-metadata) in a non-driver specific format?  
> > 
> > Having setters feels more generic than narrowly solving only the redirect,
> > but I don't have a good use-case in mind.
> >   
> > > Storing the hw-metadata in some of hw-specific format in xdp_frame will not
> > > allow to consume them directly building the skb and we will require to decode
> > > them again. What is the upside/use-case of this approach? (not considering the
> > > orthogonality with the get method).  
> > 
> > If we add the store kfuncs to regular drivers, the metadata  won't be stored
> > in the xdp_frame; it will go into the rx descriptors so regular path that
> > builds skbs will use it.  
> 
> IIUC, the described use-case would be to modify the hw metadata via a
> 'setter' kfunc executed by an eBPF program bounded to the NIC and to store
> the new metadata in the DMA descriptor in order to be consumed by the driver
> codebase building the skb, right?
> If so:
> - we can get the same result just storing (running a kfunc) the modified hw
>   metadata in the xdp_buff struct using a well-known/generic layout and
>   consume it in the driver codebase (e.g. if the bounded eBPF program
>   returns XDP_PASS) using a generic xdp utility routine. This part is not in
>   the current series.
> - Using this approach we are still not preserving the hw metadata if we pass
>   the xdp_frame to a remote CPU returning XDP_REDIRCT (we need to add more
>   code)
> - I am not completely sure if can always modify the DMA descriptor directly
>   since it is DMA mapped.
> 
> What do you think?

FWIW I commented on an earlier revision to similar effect as Stanislav.
To me the main concern is that we're adding another adhoc scheme, and
are making xdp_frame grow into a para-skb. We added XDP to make raw
packet access fast, now we're making drivers convert metadata twice :/