netdev - Re: [PATCH RFC bpf-next v2 0/5] Add the the capability to load HW RX checsum in eBPF programs

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: <87ldm12zoq.fsf@cloudflare.com>
Date: Fri, 26 Sep 2025 13:58:13 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>,  Donald Hunter
 <donald.hunter@...il.com>,  Jakub Kicinski <kuba@...nel.org>,  "David S.
 Miller" <davem@...emloft.net>,  Eric Dumazet <edumazet@...gle.com>,  Paolo
 Abeni <pabeni@...hat.com>,  Simon Horman <horms@...nel.org>,  Alexei
 Starovoitov <ast@...nel.org>,  Daniel Borkmann <daniel@...earbox.net>,
  John Fastabend <john.fastabend@...il.com>,  Stanislav Fomichev
 <sdf@...ichev.me>,  Andrew Lunn <andrew+netdev@...n.ch>,  Tony Nguyen
 <anthony.l.nguyen@...el.com>,  Przemek Kitszel
 <przemyslaw.kitszel@...el.com>,  Alexander Lobakin
 <aleksander.lobakin@...el.com>,  Andrii Nakryiko <andrii@...nel.org>,
  Martin KaFai Lau <martin.lau@...ux.dev>,  Eduard Zingerman
 <eddyz87@...il.com>,  Song Liu <song@...nel.org>,  Yonghong Song
 <yonghong.song@...ux.dev>,  KP Singh <kpsingh@...nel.org>,  Hao Luo
 <haoluo@...gle.com>,  Jiri Olsa <jolsa@...nel.org>,  Shuah Khan
 <shuah@...nel.org>,  Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
  netdev@...r.kernel.org,  bpf@...r.kernel.org,
  intel-wired-lan@...ts.osuosl.org,  linux-kselftest@...r.kernel.org,
  kernel-team <kernel-team@...udflare.com>
Subject: Re: [PATCH RFC bpf-next v2 0/5] Add the the capability to load HW
 RX checsum in eBPF programs

On Fri, Sep 26, 2025 at 01:45 PM +02, Jesper Dangaard Brouer wrote:
> On 25/09/2025 12.58, Jakub Sitnicki wrote:
>> On Thu, Sep 25, 2025 at 12:39 PM +02, Lorenzo Bianconi wrote:
>>>> On Thu, Sep 25, 2025 at 11:30 AM +02, Lorenzo Bianconi wrote:
>>>>> Introduce bpf_xdp_metadata_rx_checksum() kfunc in order to load the HW
>>>>> RX cheksum results in the eBPF program binded to the NIC.
>>>>> Implement xmo_rx_checksum callback for veth and ice drivers.
>>>>
>>>> What are going to do with HW RX checksum once XDP prog can access it?
>>>
>>> I guess there are multiple use-cases for bpf_xdp_metadata_rx_checksum()
>>> kfunc. The first the I have in mind is when packets are received by an af_xdp
>>> application. In this case I think we currently do not have any way to check if
>>> the packet checksum is correct, right?
>>> I think Jesper has other use-cases in mind, I will let him comment
>>> here.
>> Can you share more details on what the AF_XDP application would that
>> info?
>
> Today the AF_XDP application need to verify the packet checksum, as it
> gets raw xdp_frame packets directly from hardware (no layer in-between
> checked this).  Getting the RX-checksum validation from hardware info
> will be very useful for AF_XDP, as it can avoid doing this in software.
>
>
>> Regarding the use cases that Jesper is trying to unlock, as things stand
>> we don't have a way, or an agreement on how to inject/propagate even the
>> already existing NIC hints back into the network stack.
>> 
>
> This patchset have its own merits and shouldn't be connected with my
> use-case of (optionally) including hardware offloads in the xdp_frame.
> Sure, I obviously also want this RX-checksum added, but this patchset is
> useful on it's own.
>
>> Hence my question - why do we want to expose another NIC hint to XDP
>> that we can't consume in any useful way yet?
>> 
>
> Well here *are* useful ways to use this RX-checksum info on its own.
> See my explanation of the DDoS use-case here[1] in other email.
>
> Cloudflare actually also have a concrete use-case for needing this.
> Our XDP based Unimog[2] load-balancer (and DDoS) encapsulate all
> packets when they are XDP_TX forwarded. The encap receiving NIC lacking
> inner-packet checksum validation make us loose this hardware offload.
> This would allow us to save some checksum validation or even just DDOS drop
> based on hardware checksum validation prior to encap (as in [1]).

Thanks for filling in the blanks, Jesper. That's the context that I was
missing.

Lorenzo, this motivaton seems worth including in the cover letter.