netdev - Re: [PATCH bpf-next v3 00/17] Decouple skb metadata tracking from MAC header offset

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: <20260108074741.00bd532f@kernel.org>
Date: Thu, 8 Jan 2026 07:47:41 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, John
 Fastabend <john.fastabend@...il.com>, Stanislav Fomichev <sdf@...ichev.me>,
 Simon Horman <horms@...nel.org>, 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>,
 kernel-team@...udflare.com
Subject: Re: [PATCH bpf-next v3 00/17] Decouple skb metadata tracking from
 MAC header offset

On Wed, 07 Jan 2026 15:28:00 +0100 Jakub Sitnicki wrote:
> This series continues the effort to provide reliable access to xdp/skb
> metadata from BPF context on the receive path. We have recently talked
> about it at Plumbers [1].
> 
> Currently skb metadata location is tied to the MAC header offset:
> 
>   [headroom][metadata][MAC hdr][L3 pkt]
>                       ^
>                       skb_metadata_end = head + mac_header
> 
> This design breaks on L2 decapsulation (VLAN, GRE, etc.) when the MAC
> offset is reset. The naive fix is to memmove metadata on every decap path,
> but we can avoid this cost by tracking metadata position independently.
> 
> Introduce a dedicated meta_end field in skb_shared_info that records where
> metadata ends relative to skb->head:
> 
>   [headroom][metadata][gap][MAC hdr][L3 pkt]
>                      ^
>                      skb_metadata_end = head + meta_end
>                      
> This allows BPF dynptr access (bpf_dynptr_from_skb_meta()) to work without
> memmove. For skb->data_meta pointer access, which expects metadata
> immediately before skb->data, make the verifier inject realignment code in
> TC BPF prologue.

I don't understand what semantics for the buffer layout you're trying
to establish, we now have "headroom" and "gap"?

	[headroom][metadata][gap][packet]

You're not solving the encap side either, skb_push() will still happily
encroach on the metadata. Feel like duct tape, we can't fundamentally
update the layout of the skb without updating all the helpers.
metadata works perfectly fine for its intended use case - passing info
about the frame from XDP offload to XDP and then to TC.