Re: [PATCH v8 bpf-next 02/10] libbpf: Support kind layout section handling in BTF

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2025-12-19 at 10:41 -0800, Andrii Nakryiko wrote:
> On Fri, Dec 19, 2025 at 10:36 AM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > 
> > On Fri, 2025-12-19 at 10:21 -0800, Andrii Nakryiko wrote:
> > 
> > [...]
> > 
> > > > The sanitization for user-space consumption is doable alright, I was thinking
> > > > of the case where the kernel itself reads in BTF for vmlinux/modules on boot,
> > > > and that BTF was generated by newer pahole so has unexpected layout info.
> > > > If we just emitted layout info unconditionally that would mean newer pahole might
> > > > generate BTf for a kernel that it could not read. If however we relaxed the
> > > > constraints a bit I think we could get the validation to succeed for older
> > > > kernels while ignoring the bits of the BTF they don't care about. Fix that would
> > > > also potentially future-proof addition of other sections to the BTF header without
> > > > requiring options.
> > > 
> > > No, let's forget about allowing the kernel to let through some
> > > unrecognized parts of BTF. Pahole will keep introducing feature flags
> > > that we need to enable (like layout stuff, for example), so old
> > > kernels built with new pahole will be just fine. And any
> > > kernel-specific modifications will be moved to resolve_btfids and will
> > > be in-sync with kernel logic. I think we are all good and we don't
> > > have to invent new things on this front, potentially opening us up to
> > > some unforeseen attacks through BTF injection.
> > 
> > That would mean that the flag to generate or not layout information
> > should remain, right?
> 
> Yeah, unfortunately, as there will be no libbpf to sanitize that. But
> that brings the layout question for Clang/GCC, are we adding that?
> That should be emitted unconditionally, IMO.

I don't think we have layout generation in the current roadmap.
I'll add it to the plan.