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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220713011851.4a2tnqhdd5f5iwak@macbook-pro-3.dhcp.thefacebook.com>
Date:   Tue, 12 Jul 2022 18:18:51 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     James Hilliard <james.hilliard1@...il.com>
Cc:     "Jose E. Marchesi" <jose.marchesi@...cle.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Quentin Monnet <quentin@...valent.com>,
        Yonghong Song <yhs@...com>, 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 Tue, Jul 12, 2022 at 07:10:27PM -0600, James Hilliard wrote:
> On Tue, Jul 12, 2022 at 10:48 AM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Tue, Jul 12, 2022 at 4:20 AM Jose E. Marchesi
> > <jose.marchesi@...cle.com> wrote:
> > >
> > >
> > > > CC Quentin as well
> > > >
> > > > On Mon, Jul 11, 2022 at 5:11 PM James Hilliard
> > > > <james.hilliard1@...il.com> wrote:
> > > >>
> > > >> 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?
> > > >
> > > > I'm curious, is there any added benefit to having this special
> > > > kernel_helper attribute vs what we did in Clang for a long time?
> > > > Did GCC do it just to be different and require workarounds like this
> > > > or there was some technical benefit to this?
> > >
> > > We did it that way so we could make trouble and piss you off.
> > >
> > > Nah :)
> > >
> > > We did it that way because technically speaking the clang construction
> > > works relying on particular optimizations to happen to get correct
> > > compiled programs, which is not guaranteed to happen and _may_ break in
> > > the future.
> > >
> > > In fact, if you compile a call to such a function prototype with clang
> > > with -O0 the compiler will try to load the function's address in a
> > > register and then emit an invalid BPF instruction:
> > >
> > >   28:   8d 00 00 00 03 00 00 00         *unknown*
> > >
> > > On the other hand the kernel_helper attribute is bullet-proof: will work
> > > with any optimization level, with any version of the compiler, and in
> > > our opinion it is also more readable, more tidy and more correct.
> > >
> > > Note I'm not saying what you do in clang is not reasonable; it may be,
> > > obviously it works well enough for you in practice.  Only that we have
> > > good reasons for doing it differently in GCC.
> >
> > Not questioning the validity of the reasons, but they created
> > the unnecessary difference between compilers.
> 
> Sounds to me like clang is relying on an unreliable hack that may
> be difficult to implement in GCC, so let's see what's the best option
> moving forwards in terms of a migration path for both GCC and clang.

The following is a valid C code:
static long (*foo) (void) = (void *) 1234;
foo();

and GCC has to generate correct assembly assuming it runs at -O1 or higher.
There is no indirect call insn defined in BPF ISA yet,
so the -O0 behavior is undefined.

> Or we can just feature detect kernel_helper and leave the (void *)1 style
> fallback in place until we drop support for clang variants that don't support
> kernel_helper. This would provide GCC compatibility and a better migration
> path for clang as well as clang will then automatically use the new variant
> whenever support for kernel_helper is introduced.

Support for valid C code will not be dropped from clang.