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

Date:   Wed, 1 Jul 2020 09:36:50 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...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 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:

@@ -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);