netdev - Re: [PATCH RFC bpf-next v2 1/5] netlink: specs: Add XDP RX checksum capability to XDP metadata specs

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: <0608935c-1c1c-4374-a058-bc78d114c630@kernel.org>
Date: Fri, 26 Sep 2025 11:53:25 +0200
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: 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>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org,
 intel-wired-lan@...ts.osuosl.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH RFC bpf-next v2 1/5] netlink: specs: Add XDP RX checksum
 capability to XDP metadata specs

On 25/09/2025 11.30, Lorenzo Bianconi wrote:
> +/**
> + * bpf_xdp_metadata_rx_checksum - Read XDP frame RX checksum.
> + * @ctx: XDP context pointer.
> + * @ip_summed: Return value pointer indicating checksum result.
> + * @cksum_meta: Return value pointer indicating checksum result metadata.
> + *
> + * In case of success, ``ip_summed`` is set to the RX checksum result. Possible
> + * values are:
> + * ``XDP_CHECKSUM_NONE``
> + * ``XDP_CHECKSUM_UNNECESSARY``
> + * ``XDP_CHECKSUM_COMPLETE``
> + * ``XDP_CHECKSUM_PARTIAL``
> + *
> + * In case of success, ``cksum_meta`` contains the hw computed checksum value
> + * for ``XDP_CHECKSUM_COMPLETE`` or the ``csum_level`` for
> + * ``XDP_CHECKSUM_UNNECESSARY``. It is set to 0 for ``XDP_CHECKSUM_NONE`` and
> + * ``XDP_CHECKSUM_PARTIAL``.
> + *

It is very important that we explain the meaning of XDP_CHECKSUM_NONE.
As I hinted in other email, this also covers the non-existing FAIL case.

If the hardware detects a wrong or failed checksum, the code still
returns CHECKSUM_NONE. This is where we could consider adding a
CHECKSUM_FAIL return value instead.
The driver will also return CHECKSUM_NONE for the cases where it cannot
parse the packet, and therefor naturally cannot calculate the checksum
(given it doesn't know the protocol).

Thus, for CHECKSUM_NONE we don't know if this is because of bad checksum
or hardware don't know this packet type.  The philosophy is that 
hardware might be wrong and cannot know of newer protocols, so it is 
safer to let software handle recalculation of checksum for all negative 
cases.

Thus, if we want to use this in a (XDP) DDoS filter, then we need to
combine RX-hash info about if hardware saw this as an L4 packet or not
(see XDP_RSS_L4 / enum xdp_rss_hash_type).  If hardware saw this as e.g.
XDP_RSS_L4_TCP (or XDP_RSS_L4_UDP) and rx-csum is CHECKSUM_NONE, then we
know this was a wrong/failed checksum (given this hardware knows howto
csum TCP).

What do people think: Do we leave it as an exercise to the BPF-developer
to deduct hardware detected a wrong/failed checksum, as that is possible
as described above.  Or do we introduce a CHECKSUM_FAILED?

An argument for sticking with CHECKSUM_NONE, is that it will make it
much easier to add driver support, as we don't need to deal with any
logic changes in the existing code.

> + * Return:
> + * * Returns 0 on success or ``-errno`` on error.
> + * * ``-EOPNOTSUPP`` : means device driver does not implement kfunc
> + * * ``-ENODATA``    : means no RX-timestamp available for this frame
> + */
> +__bpf_kfunc int bpf_xdp_metadata_rx_checksum(const struct xdp_md *ctx,
> +					     u8 *ip_summed, u32 *cksum_meta)
> +{
> +	return -EOPNOTSUPP;
> +}
> +