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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87pldpx0od.fsf@cloudflare.com>
Date: Thu, 24 Jul 2025 13:56:02 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
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 Wed, Jul 23, 2025 at 06:54 PM -07, Martin KaFai Lau wrote:
> 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?

Good point. If we decide to implement a copy-on-write in the future,
then this will be a problem. Why tie our hands if it's not a huge
nuissance for the user? Let me restrict it.