From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 EA8F12C17A1 for ; Tue, 16 Dec 2025 21:21:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765920119; cv=none; b=YNR4q7umrRb6tMvmXid7gFxhrNJ51W79UUcIJ/NuKuwUTcPbLA3g+Aja4qi18HcCpuSY3Ybn2LF+SSwMat99I8/YTn28+pLCTBa4wqQ8fJTDWBK3iHB7jT1V1ycNgZySDxFN/w2POzcohBLeCvEIi1SkawU0LFK3WjyJ5Ws8yHE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765920119; c=relaxed/simple; bh=+QEPGr+Iu+hi73Z5uGfoueLk3SXJa149FVNfcpqUH20=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=g2UkccPaJl6mlS1I+CeX38v5QF5a3b/3H6kAUeamPUO/oBE/ovlI8crQ/r0RTPMuzW1CrDJ9/BmTsp8LYiJqx2QvxziVV4oSNllUF2ozpc1JytWLMnVd3vbdXXmuBiXio/Nzu0jER/MH1FwTqTdP/fUPIhwjQHVu7yituXBSTaM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CkMP82mH; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CkMP82mH" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-2a07fac8aa1so38837025ad.1 for ; Tue, 16 Dec 2025 13:21:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765920117; x=1766524917; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=GoGeK1g9YwKrSivRU+t+dex6Y1tJ3oax7zgFN2o+Tz4=; b=CkMP82mHxCekxV8tGXhNCddZViIjUDUA1r5O3OctRZjCzOmd20VHFBJV7m298ku1nn CcNf+aCPypQDIzy//zPPivRPAFac5vSRAdeR3Aec8HuIbak6VzK2WUh0wjToaX8kO9K8 xFa4sVYECO/UnKPtRDXxxUO849lzvSY4p7i4wW79/OGuW3S9NXwSohAFmqLWwnWu+pm0 kgNNZgPdVdkylmbLsYViKo+Zx4QLYMIN9x/AFzSU7ygFuUm6z2mVrNStrwN/bL1QAUH8 o0LOw5OlzbxFudyJ6L3BTycFFb3c1m+jqJUe1drFOyN3LbFHcsXIYDaXuOxT51EKDD+W IHbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765920117; x=1766524917; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GoGeK1g9YwKrSivRU+t+dex6Y1tJ3oax7zgFN2o+Tz4=; b=qEYvX0DcefEoy/I/KXlnGhgGUAbcDvqQNi4oK6zuz4DhSoxLW2biwGC0DMmR0nRuUC 4m19dp2LnDJ8Hj8KrxoXPKSEVW00KZ2G+UTfx04WLQvidLbXWjDXvCOGh3bouhWw4Wo2 u2fvveWlI9PNyhxjwgQJ351XtSzVc1Ze3AA1Uq8QNqF3H+tdeWkIbCOFKFaMvafkVFVQ 1tuyl3MQzvYEr62TGgJ0OwMrVfMrrhgPZCeXKVjYROpudvuRUpnX6B0TQ1BtvXbLwLCu SdZQdG3m8ZwQU6txPPtWjVlXtry+ZrO0oGadvXbm0z4ANFDz3mlGjBLaVGThnIG14wHY m3cQ== X-Forwarded-Encrypted: i=1; AJvYcCWlT0F1pOQX9Vg/aw8eFqXmg9c6sVgqClmk6cHYTbtNCto/W2uoE8GYBmEO8NiqokOqWJ6Iszt4@vger.kernel.org X-Gm-Message-State: AOJu0YxbDxcv+GqhuHbcuxdOMmFcBUS3IdGp2E8iIKgM7hgk1PHs0aTC gaIlWayIay4mhbOg6YYWbhKSGblJ1y/fq9wNw6VHR2lkzu4vlMzNbXPc X-Gm-Gg: AY/fxX4bOUldUB9R33r+nbPnaZo4Fp9X8JPvA7p+ZDqsEfNpW7i3Z8fgI4CPLh8Y8nw O3mxYVES1htqYXRRrXYnVutXIvaT7/+2o2ql/ew/T7MUF1n/nEzf3tf0sZU+dGBRAMHhFgC+Ely ED0CFTvFJiDzluE9jm/oyYFrE//wMfGgBI55cw2xdWyYqYuAXjzHnEvDZjPTkEP+NQtXFxzETus abd+xawYN1Tc9kIoMBxlJ1R+95wU56Y8i6FHCqXXmFBs/n8TFxjy/WWThBf//LNfMi/ZXkOgXFQ d4hjyQnPyJeo44twBEQu7Km5tGWusqI8YW37kRm13KdvBkOe/BuPiHgERg9k7BFDqIZfcPptlF/ DZOMeb72pLFTU/y7QEAIenLbOECn4URgeaIgILg3bazd3xXF30ZrnFMY/tiNg5ml5CMJ4MIXRat rNCvWCTlhe X-Google-Smtp-Source: AGHT+IGcHlsW1EY+4zXWrJZ6eHWfcZ72JStxzoQg5sCS39glyCCVIkQoWR1wBYREG69U1c85ZRFcpQ== X-Received: by 2002:a17:902:ebca:b0:295:86a1:5008 with SMTP id d9443c01a7336-29f23c7c568mr152233595ad.38.1765920117060; Tue, 16 Dec 2025 13:21:57 -0800 (PST) Received: from [192.168.0.226] ([38.34.87.7]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a0cf143804sm84871045ad.73.2025.12.16.13.21.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 13:21:56 -0800 (PST) Message-ID: <26e95f737d2de5133702c9b641946e70ec2d1dae.camel@gmail.com> Subject: Re: [PATCH v8 bpf-next 03/10] libbpf: use kind layout to compute an unknown kind size From: Eduard Zingerman To: Andrii Nakryiko Cc: Alan Maguire , andrii@kernel.org, ast@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org, qmo@kernel.org, ihor.solodrai@linux.dev, dwarves@vger.kernel.org, bpf@vger.kernel.org, ttreyer@meta.com, mykyta.yatsenko5@gmail.com Date: Tue, 16 Dec 2025 13:21:53 -0800 In-Reply-To: References: <20251215091730.1188790-1-alan.maguire@oracle.com> <20251215091730.1188790-4-alan.maguire@oracle.com> <9e1b071598f9c1c1adcac0d8cb2591c452a675fd.camel@gmail.com> <6f3027ee-576d-45de-9795-9a8e620292e9@oracle.com> <27e4a60100602f769f3c5410a398a75fe0151967.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: dwarves@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2025-12-16 at 13:11 -0800, Andrii Nakryiko wrote: > On Tue, Dec 16, 2025 at 11:58=E2=80=AFAM Eduard Zingerman wrote: > >=20 > > On Tue, 2025-12-16 at 11:42 -0800, Andrii Nakryiko wrote: > > > On Tue, Dec 16, 2025 at 7:00=E2=80=AFAM Alan Maguire wrote: > > > >=20 > > > > On 16/12/2025 06:07, Eduard Zingerman wrote: > > > > > On Mon, 2025-12-15 at 09:17 +0000, Alan Maguire wrote: > > > > >=20 > > > > > [...] > > > > >=20 > > > > > > @@ -395,8 +416,7 @@ static int btf_type_size(const struct btf_t= ype *t) > > > > > > case BTF_KIND_DECL_TAG: > > > > > > return base_size + sizeof(struct btf_decl_tag); > > > > > > default: > > > > > > - pr_debug("Unsupported BTF_KIND:%u\n", btf_kind(t))= ; > > > > > > - return -EINVAL; > > > > > > + return btf_type_size_unknown(btf, t); > > > > > > } > > > > > > } > > > > > >=20 > > > > >=20 > > > > > That's a matter of personal preference, of-course, but it seems t= o me > > > > > that using `kind_layouts` table from your next patch for size > > > > > computation for all kinds would be a bit more elegant. > > > > >=20 > > > > > Also, a question, should BTF validation check sizes for known kin= ds > > > > > and reject kind layout sections if those sizes differ from expect= ed? > > > > >=20 > > > >=20 > > > > yeah, I'd say we'd need your second suggestion for the first to be = safe, > > > > and it seems worthwhile doing both I think. Thanks! > > >=20 > > > ... but we will just blindly trust layout for unknown kinds, though? > > > So it's a bit inconsistent. I'd say let's keep it simple and don't > > > overdo the checking? btf_sanity_check() will validate that all known > > > kinds are well-formed, isn't that sufficient to ensure that subsequen= t > > > use of BTF data in libbpf won't crash? If some tool generated a subtl= y > > > invalid layout section which otherwise preserves BTF data > > > correctness... I don't know, this seems fine. The goal of sanity > > > checking is just to prevent more checks in all different places that > > > will subsequently rely on IDs being valid, and stuff like that. If > > > layout info is wrong for known kinds, so be it, we are not using that > > > information anyways. > >=20 > > Ignoring layout information for known kinds can lead to weird > > scenarios: e.g. suppose type size is N, but kind layout specifies that > > it is M > N, and the tool generating BTF uses M to actually layout the > > binary data. We are being a bit inconsistent with such encoding. >=20 > Who are "we" here? The tool that emitted incorrect layout information > -- yep, for sure. (But that shouldn't happen for correct BTF.) >=20 > We do btf_sanity_check() upfront to minimize various sanity checks > spread out in libbpf code when using BTF data later on. But the goal > there is not really to check "100% standards conformance" of whatever > BTF we are working with. Kernel is way more concerned about validity > and not letting anything unexpected get through, but libbpf is in user > space and it's a bit different approach there. >=20 > As long as BTF looks structurally sound (btf_sanity_check), it should > be fine for our needs. If BTF is corrupted or just uses invalid ID, or > whatnot, it will eventually fail somewhere, most probably. But the > goal is not to have NULL derefs and stuff like that. Introducing layout info into format provides an alternative definition for structural soundness. E.g. some types or vlen elements can have padding in the end all of a sudden. Using this info for some types but not the others is inconsistent. Given that BTF rewrites would only be unsound in presence of unknown types the whole feature looks questionable to me. > Basically what I'm trying to say is that if some tool intentionally or > unintentionally generates invalid layout information, but the rest of > data is valid, and libbpf doesn't look at layout and otherwise makes > fine use of BTF. Then that's fine with me, that BTF fulfills its duty > as far as libbpf is concerned. Libbpf here is just a consumer that > tries to be as permissive (unlike kernel) as possible, while not > leading to a process crash. >=20 > With double checking that layout info matches our implicit knowledge > of type layout we are starting to move into BTF verification a bit, > IMO. And I think that's misleading and unnecessary.