linux-kernel - Re: [PATCH v4] lib/string.c: implement a basic bcmp

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: <CAKwvOdn84HNEB3u4XO-V_+c=txmDd1061G_7K0zZVS4MfF--Lg@mail.gmail.com>
Date:   Thu, 21 Mar 2019 10:02:37 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     clang-built-linux@...glegroups.com,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        "# 3.4.x" <stable@...r.kernel.org>,
        Nathan Chancellor <natechancellor@...il.com>,
        Adhemerval Zanella <adhemerval.zanella@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        James Y Knight <jyknight@...gle.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Steven Rostedt <rostedt@...dmis.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] lib/string.c: implement a basic bcmp

On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Wed, 13 Mar 2019 14:13:31 -0700 Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> > A recent optimization in Clang (r355672) lowers comparisons of the
> > return value of memcmp against zero to comparisons of the return value
> > of bcmp against zero.  This helps some platforms that implement bcmp
> > more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
> > an optimized implementation is in the works.
> >
> > This results in linkage failures for all targets with Clang due to the
> > undefined symbol.  For now, just implement bcmp as a tailcail to memcmp
> > to unbreak the build.  This routine can be further optimized in the
> > future.
> >
> > Other ideas discussed:
> > * A weak alias was discussed, but breaks for architectures that define
> > their own implementations of memcmp since aliases to declarations are
> > not permitted (only definitions).  Arch-specific memcmp implementations
> > typically declare memcmp in C headers, but implement them in assembly.
> > * -ffreestanding also is used sporadically throughout the kernel.
> > * -fno-builtin-bcmp doesn't work when doing LTO.
>
> I guess we should backport this into -stable so that older kernels can
> be built with newer Clang.

Ah, you're right.  I always forget.  Is it too late to add

Cc: stable@...r.kernel.org

to the patch in your tree?

>
> > ...
> >
> > --- a/lib/string.c
> > +++ b/lib/string.c
> > @@ -866,6 +866,26 @@ __visible int memcmp(const void *cs, const void *ct, size_t count)
> >  EXPORT_SYMBOL(memcmp);
> >  #endif
> >
> > +#ifndef __HAVE_ARCH_BCMP
> > +/**
> > + * bcmp - returns 0 if and only if the buffers have identical contents.
> > + * @a: pointer to first buffer.
> > + * @b: pointer to second buffer.
> > + * @len: size of buffers.
> > + *
> > + * The sign or magnitude of a non-zero return value has no particular
> > + * meaning, and architectures may implement their own more efficient bcmp(). So
> > + * while this particular implementation is a simple (tail) call to memcmp, do
> > + * not rely on anything but whether the return value is zero or non-zero.
> > + */
> > +#undef bcmp
>
> What is the undef for?

Used the same convention as memcpy.  Looking at the rest of the
translation unit, I see that there's a mix of functions that do or do
not undef their symbol.  Rasmus pointed out that memcpy is implemented
as a macro for x86 (arch/x86/include/asm/string_32.h).  But looking
closer now, I suspect it's not needed (anyone declaring memcmp as a
macro should be setting __HAVE_ARCH_MEMCMP).

Shall I send you a cleanup removing the undefs for bcmp, memcmp,
strcat, strcpy, and strcmp?  Of those, I only see memcmp being
`#defined` in arch/m68k/include/asm/string.h, arch/x86/boot/string.h,
and arch/x86/include/asm/string_32.h.

Further, I can drop some of the __GNUC__ < 4 code in
arch/x86/include/asm/string_32.h. (grepping for __GNUC__, looks like
there's a fair amount of code that can be cleaned up).  We should
probably check it since Clang lies about being GCC 4.2 compatible,
which will surely break in horrific ways at some point.

-- 
Thanks,
~Nick Desaulniers