linux-kernel - Re: [PATCH] libbpf: add support for printing BTF character arrays as strings

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: <CAADnVQKeJUdvJ7tKhpdatL-A5zDi9DXKFun8fwM2e7Bynd5FDg@mail.gmail.com>
Date: Mon, 2 Jun 2025 11:39:07 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Ian Rogers <irogers@...gle.com>
Cc: Blake Jones <blakejones@...gle.com>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>, 
	Ihor Solodrai <ihor.solodrai@...ux.dev>, Namhyung Kim <namhyung@...nel.org>, bpf <bpf@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH] libbpf: add support for printing BTF character arrays as strings

On Mon, Jun 2, 2025 at 8:05 AM Ian Rogers <irogers@...gle.com> wrote:
>
> On Sat, May 31, 2025 at 11:20 AM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Sat, May 31, 2025 at 12:20 AM Blake Jones <blakejones@...gle.com> wrote:
> > >
> > > The BTF dumper code currently displays arrays of characters as just that -
> > > arrays, with each character formatted individually. Sometimes this is what
> > > makes sense, but it's nice to be able to treat that array as a string.
> > >
> > > This change adds a special case to the btf_dump functionality to allow
> > > arrays of single-byte integer values to be printed as character strings.
> > > Characters for which isprint() returns false are printed as hex-escaped
> > > values. This is enabled when the new ".print_strings" is set to 1 in the
> > > btf_dump_type_data_opts structure.
> > >
> > > As an example, here's what it looks like to dump the string "hello" using
> > > a few different field values for btf_dump_type_data_opts (.compact = 1):
> > >
> > > - .print_strings = 0, .skip_names = 0:  (char[6])['h','e','l','l','o',]
> > > - .print_strings = 0, .skip_names = 1:  ['h','e','l','l','o',]
> > > - .print_strings = 1, .skip_names = 0:  (char[6])"hello"
> > > - .print_strings = 1, .skip_names = 1:  "hello"
> > >
> > > Here's the string "h\xff", dumped with .compact = 1 and .skip_names = 1:
> > >
> > > - .print_strings = 0:  ['h',-1,]
> > > - .print_strings = 1:  "h\xff"
> > >
> > > Signed-off-by: Blake Jones <blakejones@...gle.com>
> > > ---
> > >  tools/lib/bpf/btf.h                           |   3 +-
> > >  tools/lib/bpf/btf_dump.c                      |  51 ++++++++-
> > >  .../selftests/bpf/prog_tests/btf_dump.c       | 102 ++++++++++++++++++
> > >  3 files changed, 154 insertions(+), 2 deletions(-)
> >
> > Please split selftests vs main libbpf parts.
> >
> > > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > > index 4392451d634b..be8e8e26d245 100644
> > > --- a/tools/lib/bpf/btf.h
> > > +++ b/tools/lib/bpf/btf.h
> > > @@ -326,9 +326,10 @@ struct btf_dump_type_data_opts {
> > >         bool compact;           /* no newlines/indentation */
> > >         bool skip_names;        /* skip member/type names */
> > >         bool emit_zeroes;       /* show 0-valued fields */
> > > +       bool print_strings;     /* print char arrays as strings */
> > >         size_t :0;
> > >  };
> > > -#define btf_dump_type_data_opts__last_field emit_zeroes
> > > +#define btf_dump_type_data_opts__last_field print_strings
> > >
> > >  LIBBPF_API int
> > >  btf_dump__dump_type_data(struct btf_dump *d, __u32 id,
> > > diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
> > > index 460c3e57fadb..a07dd5accdd8 100644
> > > --- a/tools/lib/bpf/btf_dump.c
> > > +++ b/tools/lib/bpf/btf_dump.c
> > > @@ -75,6 +75,7 @@ struct btf_dump_data {
> > >         bool is_array_member;
> > >         bool is_array_terminated;
> > >         bool is_array_char;
> > > +       bool print_strings;
> >
> > Looks useful, but make sure to add a feature detection
> > to perf, since it has to work with old and new libbpf.
>
> Just for clarity on this. We'll need a "libbpf-strings" feature like
> the existing "libbpf" one:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/build/feature/test-libbpf.c?h=perf-tools-next
>
> Currently these features are only used if perf is built with
> LIBBPF_DYNAMIC=1 as part of the build arguments (ie its not the
> default):
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.config?h=perf-tools-next#n580
>
> If no suitable libbpf is detected then the build will error out. I
> guess if feature-libbpf is present but not feature-libbpf-strings then
> we'll need a perf #define so that the string feature won't cause
> perf's build to fail.

Yes. Something like this.
It will also allow libbpf and perf patches to land in parallel.