From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 93B2C20E717 for ; Wed, 23 Jul 2025 17:36:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753292213; cv=none; b=ZpmccWcH7WUnkhbpvhnpFkyf3fTbqp5hQS54Nr0bbsCZ6nlpR5x69ZDjz6gAGg1fzCcjUR2ESSxf4uOqI6lNWCOXh6lN1MUL6N4G3Hx/rGRJqacVZSeUN4FOiBS/0eKWUn2W8F85Vf89EUzD2zvPJP2Dq9tIEpaFqo8OwSxqatE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753292213; c=relaxed/simple; bh=BGm2ukabBejPap75JlSTwrFukpdyn3UUJRvuUCo/RHc=; h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=mM0lwsKaVt99KVqxsNL7Lz2Cy/bZIZe4bg+ri1X6mv1eXhTWF4VWd6EN3Z5mOydkPXTMwmvlQhv4sGOeT0sJFtdD166OB0wdLfumcLdNFxkYCf1lRQa3gNPtb6tZzUUAxMMuU5AoGkDF70PWqRZ09s1ygHZVDfUI2hF2FU4Tlis= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=bQDMlSKp; arc=none smtp.client-ip=209.85.218.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="bQDMlSKp" Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-ae0dffaa8b2so20632066b.0 for ; Wed, 23 Jul 2025 10:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1753292210; x=1753897010; darn=vger.kernel.org; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:from:to:cc:subject:date:message-id:reply-to; bh=3OrkDHN4Pu3640RJe+OMQQn8FEQX+p7+yP0jdnsqDiw=; b=bQDMlSKpIzBIqVQa/A+xTUOhPk+RyRHSDE05dYvk9iAHxUySGbEv5l3JKI/0wa+sSA 7HkOG9LiwSPVBiGpvQqwtCiYuUPBxNNw5LB0eU1JL5/W5/pnrPDrqh8aTVzpOT6tftK0 8bxAhXIPCCyBO46ZYkiluhZgW5k8Y2bMWGPAzzREq8/mfQR5STBnlWApJZP9Hh1mVsPc 8ulPDt5skEfD5MKs8qePXHYMmjBzgTgBU8he+oPCidFakKkzwBhhACmSyHG5zxJjFD99 k+hUNIhmuvpK17M0blSgWQHXc+2MaatKESQflB0V9XSJ66FTyHQQrNXAl5uFs6UsEawq a7Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753292210; x=1753897010; h=cc:to:content-transfer-encoding:mime-version:message-id:date :subject:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3OrkDHN4Pu3640RJe+OMQQn8FEQX+p7+yP0jdnsqDiw=; b=fskBKLgXLvM659rvQZST1xQO2Qx6NE3XUMWuTuZW9871C9A2fLw4x119jcBsVj6FLk pT4wuk5rdLBfgMRa5ikKLx0oFwIhaKiJbk73s9FHX0aKOgx7SJHpA1kY32Yfcl6mx18R YAErwZQrewRL+y/sUGlIojho+u1c29p3ofdnw2Dw2N4+HiaUkrDZr8Hc2w0WN56lb+Wv MXAKzTMsnf3kyq4hEDn8rCb4eZKm3o7rE9dlWTMKixI23GQtVwvqXHn5mVOdfpuyTrNu s69yjb2oBu3kArWwtSdkyDEkEZEbV3U00euPuRYHZdZFVewvfpTInApzGRqBj/knDJsl kuiA== X-Forwarded-Encrypted: i=1; AJvYcCUF3XLr/UIZUt3fGmBt+3smDYemo1gIOuPzkHfX3kyICNHMGWI4Kr1bt4vkHue/NbLMY8i6p4Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxYTLcrGAv2My/qS7nF5mNqjLbg5ub0j7dyMTTVRBH6qUWlI/N7 iplbH752tCtjuiKNGTiry4Owp2WGpMoZhaRApwRoBEOvGR+fGrjBaMDYp6xJxWk9FWGzfn6Hfwu l0UmV X-Gm-Gg: ASbGnctzdahB1kuN1NefR0WKKH1DXCczGWruqH/lCN0+RtVxqLHjwBVNZOC4MCMumZY 7FMFSyELvipJizHU+HSP7hs0oONyaZnvBnUIi9lZf4M6z0BnpmgcgjMRyqXqcH7Cuwu7t4cXV8w aOfpeYdSkF4Wa7vRayTOWyJlxckRXa0U+EEF+1A9RqEvRnd9VZAZIu5Mjn1ugP/NvEu4q0+BLbZ 0aL059wUsFn4SwhqxaTKold7Hk38fxr2EPDrw5qLxh3SQo/cvZcsMf4Vg4dckxZVjUtRwdOpimy dzvBchlV+Q0/NFbFgKLPSWLeFiRrLdW00DLqRDDl6UJxTdCFei7fvwH5RML4WNKcExEqgTZmdFr Qw6z0aB3hsM6Zl7IZArkMeamjRGd9bWHc/NFe5b6Qm/86Nms6ARhinXCJm9quX+6JLqds8AY= X-Google-Smtp-Source: AGHT+IGdX1BtAcPU6NXapcTHJ4XJ3l3KZ7udHFpF/bYGsc+3o9bl8p1p/WT/ndlJtRRzjAI8J+Q4Uw== X-Received: by 2002:a17:907:c26:b0:ae3:d5f2:393a with SMTP id a640c23a62f3a-af2f8d4c052mr339922066b.44.1753292209720; Wed, 23 Jul 2025 10:36:49 -0700 (PDT) Received: from cloudflare.com (79.184.149.187.ipv4.supernova.orange.pl. [79.184.149.187]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aec6ca2ec42sm1080623766b.78.2025.07.23.10.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jul 2025 10:36:49 -0700 (PDT) From: Jakub Sitnicki Subject: [PATCH bpf-next v4 0/8] Add a dynptr type for skb metadata for TC BPF Date: Wed, 23 Jul 2025 19:36:45 +0200 Message-Id: <20250723-skb-metadata-thru-dynptr-v4-0-a0fed48bcd37@cloudflare.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-B4-Tracking: v=1; b=H4sIAK0dgWgC/33OywrCMBAF0F+RrB3Js1FX/oe4SJuJDWpbkjQo0 n831IWCj+XlMufOnUQMHiPZLu4kYPbR910JcrkgTWu6I4K3JRNOuaIVqyCearhgMtYkA6kNI9h bN6QAsjZK60ZYqiQp50NA568zvSf14KDDayKH0rQ+pj7c5s3M5v7JC/qbzwwoOKatYaLiyq53z bkfrTubgKumv8xy5i9N/3s286Ipp9ZUSo3Muq+aeNM4+6OJouGG16iUkEzLD22apgdQDDdLawE AAA== X-Change-ID: 20250616-skb-metadata-thru-dynptr-4ba577c3d054 To: bpf@vger.kernel.org Cc: Alexei Starovoitov , Andrii Nakryiko , Arthur Fabre , Daniel Borkmann , Eduard Zingerman , Eric Dumazet , Jakub Kicinski , Jesper Dangaard Brouer , Jesse Brandeburg , Joanne Koong , Lorenzo Bianconi , Martin KaFai Lau , =?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Yan Zhai , kernel-team@cloudflare.com, netdev@vger.kernel.org, Stanislav Fomichev X-Mailer: b4 0.15-dev-07fe9 TL;DR ----- This is the first step in an effort which aims to enable skb metadata access for all BPF programs which operate on an skb context. By skb metadata we mean the custom metadata area which can be allocated from an XDP program with the bpf_xdp_adjust_meta helper [1]. Network stack code accesses it using the skb_metadata_* helpers. Changelog --------- Changes in v4: - Kill bpf_dynptr_from_skb_meta_rdonly. Not needed for now. (Marin) - Add a test to cover passing OOB offsets to dynptr ops. (Eduard) - Factor out bounds checks from bpf_dynptr_{read,write,slice}. (Eduard) - Squash patches: bpf: Enable read access to skb metadata with bpf_dynptr_read bpf: Enable write access to skb metadata with bpf_dynptr_write bpf: Enable read-write access to skb metadata with dynptr slice - Kept Eduard's Acks for v3 on unchanged patches. - Link to v3: https://lore.kernel.org/r/20250721-skb-metadata-thru-dynptr-v3-0-e92be5534174@cloudflare.com Changes in v3: - Add a kfunc set for skb metadata access. Limited to TC BPF. (Martin) - Drop patches related to skb metadata access outside of TC BPF: net: Clear skb metadata on handover from device to protocol selftests/bpf: Cover lack of access to skb metadata at ip layer selftests/bpf: Count successful bpf program runs - Link to v2: https://lore.kernel.org/r/20250716-skb-metadata-thru-dynptr-v2-0-5f580447e1df@cloudflare.com Changes in v2: - Switch to a dedicated dynptr type for skb metadata (Andrii) - Add verifier test coverage since we now touch its code - Add missing test coverage for bpf_dynptr_adjust and access at an offset - Link to v1: https://lore.kernel.org/r/20250630-skb-metadata-thru-dynptr-v1-0-f17da13625d8@cloudflare.com Overview -------- Today, the skb metadata is accessible only by the BPF TC ingress programs through the __sk_buff->data_meta pointer. We propose a three step plan to make skb metadata available to all other BPF programs which operate on skb objects: 1) Add a dynptr type for skb metadata (this patch set) This is a preparatory step, but it also stands on its own. Here we enable access to the skb metadata through a bpf_dynptr, the same way we can already access the skb payload today. As the next step (2), we want to relocate the metadata as skb travels through the network stack in order to persist it. That will require a safe way to access the metadata area irrespective of its location. This is where the dynptr [2] comes into play. It solves exactly that problem. A dynptr to skb metadata can be backed by a memory area that resides in a different location depending on the code path. 2) Persist skb metadata past the TC hook (future) Having the metadata in front of the packet headers as the skb travels through the network stack is problematic - see the discussion of alternative approaches below. Hence, we plan to relocate it as necessary past the TC hook. Where to relocate it? We don't know yet. There are a couple of options: (i) move it to the top of skb headroom, or (ii) allocate dedicated memory for it. They are not mutually exclusive. The right solution might be a mix. When to relocate it? That is also an open question. It could be done during device to protocol handover or lazily when headers get pushed or headroom gets resized. 3) skb dynptr for sockops, sk_lookup, etc. (future) There are BPF program types don't operate on __sk_buff context, but either have, or could have, access to the skb itself. As a final touch, we want to provide a way to create an skb metadata dynptr for these program types. TIMTOWDI -------- Alternative approaches which we considered: * Keep the metadata always in front of skb->data We think it is a bad idea for two reasons, outlined below. Nevertheless we are open to it, if necessary. 1) Performance concerns It would require the network stack to move the metadata on each header pull/push - see skb_reorder_vlan_header() [3] for an example. While doable, there is an expected performance overhead. 2) Potential for bugs In addition to updating skb_push/pull and pskp_expand_head, we would need to audit any code paths which operate on skb->data pointer directly without going through the helpers. This creates a "known unknown" risk. * Design a new custom metadata area from scratch We have tried that in Arthur's patch set [4]. One of the outcomes of the discussion there was that we don't want to have two places to store custom metadata. Hence the change of approach to make the existing custom metadata area work. -jkbs [1] https://docs.ebpf.io/linux/helper-function/bpf_xdp_adjust_meta/ [2] https://docs.ebpf.io/linux/concepts/dynptrs/ [3] https://elixir.bootlin.com/linux/v6.16-rc6/source/net/core/skbuff.c#L6211 [4] https://lore.kernel.org/all/20250422-afabre-traits-010-rfc2-v2-0-92bcc6b146c9@arthurfabre.com/ --- To: bpf@vger.kernel.org Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Arthur Fabre Cc: Daniel Borkmann Cc: Eduard Zingerman Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Jesper Dangaard Brouer Cc: Jesse Brandeburg Cc: Joanne Koong Cc: Lorenzo Bianconi Cc: Martin KaFai Lau Cc: Stanislav Fomichev Cc: Toke Høiland-Jørgensen Cc: Yan Zhai Cc: kernel-team@cloudflare.com Cc: netdev@vger.kernel.org Signed-off-by: Jakub Sitnicki --- Jakub Sitnicki (8): bpf: Add dynptr type for skb metadata bpf: Enable read/write access to skb metadata through a dynptr selftests/bpf: Cover verifier checks for skb_meta dynptr type selftests/bpf: Pass just bpf_map to xdp_context_test helper selftests/bpf: Parametrize test_xdp_context_tuntap selftests/bpf: Cover read access to skb metadata via dynptr selftests/bpf: Cover write access to skb metadata via dynptr selftests/bpf: Cover read/write to skb metadata at an offset include/linux/bpf.h | 7 +- include/linux/filter.h | 18 ++ kernel/bpf/helpers.c | 7 + kernel/bpf/log.c | 2 + kernel/bpf/verifier.c | 12 +- net/core/filter.c | 66 ++++++ tools/testing/selftests/bpf/bpf_kfuncs.h | 3 + tools/testing/selftests/bpf/prog_tests/dynptr.c | 1 + .../bpf/prog_tests/xdp_context_test_run.c | 97 ++++++-- tools/testing/selftests/bpf/progs/dynptr_fail.c | 258 +++++++++++++++++++++ tools/testing/selftests/bpf/progs/dynptr_success.c | 22 ++ tools/testing/selftests/bpf/progs/test_xdp_meta.c | 228 ++++++++++++++++++ 12 files changed, 704 insertions(+), 17 deletions(-)