netdev - Re: [PATCH bpf-next 0/3] Strip away modifiers from BPF skeleton global variables

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] [day] [month] [year] [list]

Message-ID: <CAEf4BzYqmNvhZ5ZkEHJsBRZYiMR5Muvn0QFCzV+XJek8jML4jw@mail.gmail.com>
Date:   Wed, 1 Jul 2020 11:15:24 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>,
        Anton Protopopov <a.s.protopopov@...il.com>
Subject: Re: [PATCH bpf-next 0/3] Strip away modifiers from BPF skeleton
 global variables

On Wed, Jul 1, 2020 at 9:36 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Wed, Jul 01, 2020 at 09:08:45AM -0700, Andrii Nakryiko wrote:
> > On Wed, Jul 1, 2020 at 8:02 AM Alexei Starovoitov
> > <alexei.starovoitov@...il.com> wrote:
> > >
> > > On Tue, Jun 30, 2020 at 11:46 PM Andrii Nakryiko <andriin@...com> wrote:
> > > >
> > > > Fix bpftool logic of stripping away const/volatile modifiers for all global
> > > > variables during BPF skeleton generation. See patch #1 for details on when
> > > > existing logic breaks and why it's important. Support special .strip_mods=true
> > > > mode in btf_dump. Add selftests validating that everything works as expected.
> > >
> > > Why bother with the flag?
> >
> > You mean btf_dump should do this always? That's a bit too invasive a
> > change, I don't like it.
> >
> > > It looks like bugfix to me.
> >
> > It can be considered a bug fix for bpftool's skeleton generation, but
> > it depends on non-trivial changes in libbpf, which are not bug fix per
> > se, so should probably better go through bpf-next.
>
> I'm not following.
> Without tweaking opts and introducing new flag the actual fix is only
> two hunks in patch 1:

Right, but from the btf_dump point of view this is not a bug fix, its
current behavior is correct and precise. So this change is a change in
behavior and not universally correct for all the possible use cases.
So I can't just make it always strip modifiers, it's changing
generated output. It has to be an optional feature.


>
> @@ -1045,6 +1050,10 @@ static void btf_dump_emit_type_decl(struct btf_dump *d, __u32 id,
>
>         stack_start = d->decl_stack_cnt;
>         for (;;) {
> +               t = btf__type_by_id(d->btf, id);
> +               if (btf_is_mod(t))
> +                       goto skip_mod;
> +
>                 err = btf_dump_push_decl_stack_id(d, id);
>                 if (err < 0) {
>                         /*
> @@ -1056,12 +1065,11 @@ static void btf_dump_emit_type_decl(struct btf_dump *d, __u32 id,
>                         d->decl_stack_cnt = stack_start;
>                         return;
>                 }
> -
> +skip_mod:
>                 /* VOID */
>                 if (id == 0)
>                         break;
>
> -               t = btf__type_by_id(d->btf, id);
>