On Fri, Nov 5, 2021 at 7:34 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes:
>
> > On Thu, Nov 4, 2021 at 5:29 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote:
> >>
> >> When loading a BPF object, libbpf will output a log message when it
> >> encounters an unrecognised data section. Since commit
> >> 50e09460d9f8 ("libbpf: Skip well-known ELF sections when iterating ELF")
> >> they are printed at "info" level so they will show up on the console by
> >> default.
> >>
> >> The rationale in the commit cited above is to "increase visibility" of such
> >> errors, but there can be legitimate, and completely harmless, uses of extra
> >> data sections. In particular, libxdp uses custom data sections to store
> >
> > What if we make those extra sections to be ".rodata.something" and
> > ".data.something", but without ALLOC flag in ELF, so that libbpf won't
> > create maps for them. Libbpf also will check that program code never
> > references anything from those sections.
> >
> > The worry I have about allowing arbitrary sections is that if in the
> > future we want to add other special sections, then we might run into a
> > conflict with some applications. So having some enforced naming
> > convention would help prevent this. WDYT?
>
> Hmm, I see your point, but as the libxdp example shows, this has not
> really been "disallowed" before. I.e., having these arbitrary sections
> has worked just fine.
A bunch of things were not disallowed, but that is changing for libbpf
1.0, so now is the right time :)
>
> How about we do the opposite: claim a namespace for future libbpf
> extensions and disallow (as in, hard fail) if anything unrecognised is
> in those sections? For instance, this could be any section names
> starting with .BPF?
Looking at what we added (.maps, .kconfig, .ksym), there is no common
prefix besides ".". I'd be ok to reserve anything starting with "."
for future use by libbpf. We can allow any non-dot section without a
warning (but it would have to be non-allocatable section). Would that
work?
>
> -Toke
>
