netdev - Re: [PATCH bpf-next v4 1/8] bpf: Add dynptr type for skb metadata

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 for Android: free password hash cracker in your pocket

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

Message-ID: <00a19156-cf90-48ca-be91-6c218b317044@linux.dev>
Date: Wed, 23 Jul 2025 18:54:53 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
 Arthur Fabre <arthur@...hurfabre.com>, Daniel Borkmann
 <daniel@...earbox.net>, Eduard Zingerman <eddyz87@...il.com>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Jesper Dangaard Brouer <hawk@...nel.org>,
 Jesse Brandeburg <jbrandeburg@...udflare.com>,
 Joanne Koong <joannelkoong@...il.com>, Lorenzo Bianconi
 <lorenzo@...nel.org>, Toke Høiland-Jørgensen
 <thoiland@...hat.com>, Yan Zhai <yan@...udflare.com>,
 kernel-team@...udflare.com, netdev@...r.kernel.org,
 Stanislav Fomichev <sdf@...ichev.me>, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v4 1/8] bpf: Add dynptr type for skb metadata

On 7/23/25 10:36 AM, Jakub Sitnicki wrote:
> More importantly, it abstracts away the fact where the storage for the
> custom metadata lives, which opens up the way to persist the metadata by
> relocating it as the skb travels through the network stack layers.
> 
> A notable difference between the skb and the skb_meta dynptr is that writes
> to the skb_meta dynptr don't invalidate either skb or skb_meta dynptr
> slices, since they cannot lead to a skb->head reallocation.

There is not much visibility on how the metadata will be relocated, so trying to 
think out loud. The "no invalidation after bpf_dynptr_write(&meta_dynptr, ..." 
behavior will be hard to change in the future. Will this still hold in the 
future when the metadata can be preserved?

Also, following up on Kuba's point about clone skb, what if the bpf prog wants 
to write metadata to a clone skb in the future by using bpf_dynptr_write?