linux-kernel - Re: [PATCH v2] bpf/scripts: Generate GCC compatible helpers

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: <CADvTj4ovwExtM-bWUpJELy-OqsT=J9stmqbAXto8ds2n+G8mfw@mail.gmail.com>
Date:   Mon, 11 Jul 2022 18:11:21 -0600
From:   James Hilliard <james.hilliard1@...il.com>
To:     Yonghong Song <yhs@...com>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tom Rix <trix@...hat.com>, Networking <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        llvm@...ts.linux.dev
Subject: Re: [PATCH v2] bpf/scripts: Generate GCC compatible helpers

On Mon, Jul 11, 2022 at 5:36 PM Yonghong Song <yhs@...com> wrote:
>
>
>
> On 7/6/22 10:28 AM, James Hilliard wrote:
> > The current bpf_helper_defs.h helpers are llvm specific and don't work
> > correctly with gcc.
> >
> > GCC appears to required kernel helper funcs to have the following
> > attribute set: __attribute__((kernel_helper(NUM)))
> >
> > Generate gcc compatible headers based on the format in bpf-helpers.h.
> >
> > This adds conditional blocks for GCC while leaving clang codepaths
> > unchanged, for example:
> >       #if __GNUC__ && !__clang__
> >       void *bpf_map_lookup_elem(void *map, const void *key) __attribute__((kernel_helper(1)));
> >       #else
> >       static void *(*bpf_map_lookup_elem)(void *map, const void *key) = (void *) 1;
> >       #endif
>
> It does look like that gcc kernel_helper attribute is better than
> '(void *) 1' style. The original clang uses '(void *) 1' style is
> just for simplicity.

Isn't the original style going to be needed for backwards compatibility with
older clang versions for a while?

>
> Do you mind to help implement similar attribute in clang so we
> don't need "#if" here?

That's well outside my area of expertise unfortunately.

>
> >
> >       #if __GNUC__ && !__clang__
> >       long bpf_map_update_elem(void *map, const void *key, const void *value, __u64 flags) __attribute__((kernel_helper(2)));
> >       #else
> >       static long (*bpf_map_update_elem)(void *map, const void *key, const void *value, __u64 flags) = (void *) 2;
> >       #endif
> >
> > See:
> > https://github.com/gcc-mirror/gcc/blob/releases/gcc-12.1.0/gcc/config/bpf/bpf-helpers.h#L24-L27
> >
> > This fixes the following build error:
> > error: indirect call in function, which are not supported by eBPF
> >
> > Signed-off-by: James Hilliard <james.hilliard1@...il.com>
> > ---
> > Changes v1 -> v2:
> >    - more details in commit log
> > ---
> >   scripts/bpf_doc.py | 43 ++++++++++++++++++++++++++-----------------
> >   1 file changed, 26 insertions(+), 17 deletions(-)
> >
> [...]