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: <CAEf4BzadCR+QFy4UY8NSVFjGJF4CszhjjZ48XeeqrfX3aYTnkA@mail.gmail.com>
Date:   Fri, 23 Apr 2021 16:35:32 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Yonghong Song <yhs@...com>, Andrii Nakryiko <andrii@...nel.org>,
        bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 2/6] libbpf: rename static variables during linking

On Fri, Apr 23, 2021 at 4:06 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Fri, Apr 23, 2021 at 2:56 PM Yonghong Song <yhs@...com> wrote:
> > >>>
> > >>> -static volatile const __u32 print_len;
> > >>> -static volatile const __u32 ret1;
> > >>> +volatile const __u32 print_len = 0;
> > >>> +volatile const __u32 ret1 = 0;
> > >>
> > >> I am little bit puzzled why bpf_iter_test_kern4.c is impacted. I think
> > >> this is not in a static link test, right? The same for a few tests below.
> > >
> > > All the selftests are passed through a static linker, so it will
> > > append obj_name to each static variable. So I just minimized use of
> > > static variables to avoid too much code churn. If this variable was
> > > static, it would have to be accessed as
> > > skel->rodata->bpf_iter_test_kern4__print_len, for example.
> >
> > Okay this should be fine. selftests/bpf specific. I just feel that
> > some people may get confused if they write/see a single program in
> > selftest and they have to use obj_varname format and thinking this
> > is a new standard, but actually it is due to static linking buried
> > in Makefile. Maybe add a note in selftests/README.rst so we
> > can point to people if there is confusion.
>
> I'm not sure I understand.
> Are you saying that
> bpftool gen object out_file.o in_file.o
> is no longer equivalent to llvm-strip ?
> Since during that step static vars will get their names mangled?

Yes. Static vars and static maps. We don't allow (yet?) static
entry-point BPF programs, so those don't change.

> So a good chunk of code that uses skeleton right now should either
> 1. don't do the linking step
> or
> 2. adjust their code to use global vars
> or
> 3. adjust the usage of skel.h in their corresponding user code
>   to accommodate mangled static names?
> Did it get it right?

Yes, you are right. But so far most cases outside of selftest that
I've seen don't use static variables (partially because they need
pesky volatile to be visible from user-space at all), global vars are
much nicer in that regard. So I don't expect much changes to existing
skeleton users. But ultimately yes, going from non-statically linked
to statically linked might require few adjustments.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ