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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP_z_CgGAFydp2qVGtUEive=ipWToqzuO-7w13PBSHVhYzhhdQ@mail.gmail.com>
Date: Mon, 2 Jun 2025 21:47:43 -0700
From: Blake Jones <blakejones@...gle.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: 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>, 
	Ian Rogers <irogers@...gle.com>, bpf@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] libbpf: add support for printing BTF character arrays as strings

Hi Andrii,

Thanks for your careful review.

On Mon, Jun 2, 2025 at 5:06 PM Andrii Nakryiko
<andrii.nakryiko@...il.com> wrote:
> > +       bool print_strings;     /* print char arrays as strings */
>
> let's use "emit_strings" naming, so it's consistent with emit_zeroes?

Done.

> > @@ -75,6 +75,7 @@ struct btf_dump_data {
> > [...]
> > +       bool print_strings;
>
> ditto, emit_strings (and maybe put it next to emit_zeroes then)

Done.

> > +static int btf_dump_string_data(struct btf_dump *d,
> > [...]
> > +       if (!btf_is_int(skip_mods_and_typedefs(d->btf, array->type, NULL)) ||
> > +           btf__resolve_size(d->btf, array->type) != 1 ||
> > +           !d->typed_dump->print_strings) {
> > +               pr_warn("unexpected %s() call for array type %u\n",
> > +                       __func__, array->type);
> > +               return -EINVAL;
> > +       }
> > +
>
> IMO, a bit too defensive. You literally checked that we have char[] in
> the caller, I think it's fine not to double-check that here, let's
> drop this

Done.

> > +               if (c == '\0') {
> > +                       /* When printing character arrays as strings, NUL bytes
> > +                        * are always treated as string terminators; they are
> > +                        * never printed.
> > +                        */
> > +                       break;
>
> what if there are non-zero characters after the terminating zero?
> should we keep going and if there is any non-zero one, still emit
> them? or maybe that should be an extra option?... When capturing some
> data and dumping, it might be important to know all the contents (it
> might be garbage or not, but you'll still see non-garbage values
> before \0, so maybe it's fine to always do it?)

I was thinking of this option as being optimized for common-case
pretty-printing, rather than being the ideal tool for displaying arbitrary
character arrays. If there are garbage values that are worth displaying,
btf_dump() without the ".emit_strings" option would still show them.

> > +static int find_char_array_type(struct btf *btf, int nelems)
> > [...]
> > +               if (btf_kind(t) != BTF_KIND_ARRAY)
>
> btf_is_array()

Removed, in light of your next comment.

> > +static int btf_dump_string_data(struct btf *btf, struct btf_dump *d,
> > [...]
> > +       snprintf(name, sizeof(name), "char[%zu]", ptr_sz);
> > +       type_id = find_char_array_type(btf, ptr_sz);
>
> instead of trying to find a suitable type in kernel BTF, just generate
> a tiny custom BTF with necessary char[N] types? see btf__add_xxx()
> usage for an example.

Ah thanks, that's a much better approach. Fixed.

I'll send out an updated version of these changes with the
comments I've received so far.

Blake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ