netdev - Re: [PATCH bpf-next v4 2/8] bpf: Enable read/write access to skb metadata through a dynptr

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: <87tt31x0sb.fsf@cloudflare.com>
Date: Thu, 24 Jul 2025 13:53:40 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: bpf@...r.kernel.org,  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>,  Jesper Dangaard
 Brouer <hawk@...nel.org>,  Jesse Brandeburg <jbrandeburg@...udflare.com>,
  Joanne Koong <joannelkoong@...il.com>,  Lorenzo Bianconi
 <lorenzo@...nel.org>,  Martin KaFai Lau <martin.lau@...ux.dev>,  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>
Subject: Re: [PATCH bpf-next v4 2/8] bpf: Enable read/write access to skb
 metadata through a dynptr

On Wed, Jul 23, 2025 at 05:30 PM -07, Jakub Kicinski wrote:
> On Wed, 23 Jul 2025 19:36:47 +0200 Jakub Sitnicki wrote:
>> Now that we can create a dynptr to skb metadata, make reads to the metadata
>> area possible with bpf_dynptr_read() or through a bpf_dynptr_slice(), and
>> make writes to the metadata area possible with bpf_dynptr_write() or
>> through a bpf_dynptr_slice_rdwr().
>
> What are the expectations around the writes? Presumably we could have
> two programs writing into the same metadata if the SKB is a clone, no?

In this series we maintain the status quo. Access metadata dynptr is
limited to TC BPF hook only, so we provide the same guarntees as the
existing __sk_buff->data_meta.

Current situation, as I understand it, is that while packet taps are not
an issue, you could probably do naughty things with 'tc action mirred'
and end up with concurrent writes.

Taking about the next step, once skb metadata is preserved past the TC
hook - here my impression from Netdev was that the least suprising thing
to do will be to copy-on-clone or copy-on-write (if we can pull it off).