linux-kernel - Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

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: <CAHk-=whn91ar+EbcBXQb9UXad00Q5WjU-TCB6UBzVba682a4ew@mail.gmail.com>
Date:   Thu, 20 Aug 2020 16:33:03 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Arvind Sankar <nivedita@...m.mit.edu>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Dávid Bolvanský <david.bolvansky@...il.com>,
        Eli Friedman <efriedma@...cinc.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Tony Luck <tony.luck@...el.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Joe Perches <joe@...ches.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Daniel Axtens <dja@...ens.net>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        Yury Norov <yury.norov@...il.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Paul E . McKenney" <paulmck@...nel.org>,
        Daniel Kiper <daniel.kiper@...cle.com>,
        Bruce Ashfield <bruce.ashfield@...il.com>,
        Marco Elver <elver@...gle.com>,
        Vamshi K Sthambamkadi <vamshi.k.sthambamkadi@...il.com>
Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

On Thu, Aug 20, 2020 at 10:56 AM Arvind Sankar <nivedita@...m.mit.edu> wrote:
>
> Clang's interpretation is more useful for embedded, since you can use
> -fno-builtin-foo and avoid calling __builtin_foo directly, and be
> guaranteed that there will be no calls to foo that you didn't write
> explicitly (outside of memcpy/memset/memcmp). In this case you are free
> to implement foo with non-standard semantics, or avoid implementing it
> altogether, and be reasonably confident that it will all work.

Honestly, I think concentrating on whether __builtin_foo() works or
not misses the point entirely.

That has never _ever_ been a problem for us, and I doubt it has been a
problem for anybody else either.

If you use __builtin_memcpy() in your source tree, then why would you
possibly ever want to disable it? And if you _don't_ use it, then
again - why would you ever want to disable it?

No, the real (and only) problem has always been about the compilers
magically and silently "recognizing" certain source patterns, and
turning them into function calls behind the users back.

And that has nothing to do with __builtin_foo(). At least it
_shouldn't_ have anything to do with it.

So this is things like the compiler silently seeing "oh, you called
your function 'free()', so we know that the stores you did to it are
dead and we'll remove them".

Or this is the compiler doing "Oh, you did four stores of zero in a
row, and and you asked for size optimizations, so we'll turn those
into a 'bzero()' call".

Or the compiler doing completely broken things, and turning a
"!memcmp()" expression into a "!bcmp()" because the compilier
incorrectly assumes it's faster.

Notice? Not a single one of those had any __builtin_xyz() pattern in
them. Quite the reverse. The compiler took something completely
different, and assumed builtin semantics without us having told it to.

So I think "-fno-builtin-xyz" is barking *completely* up the wrong
tree. It's missing the problem. The problem is not "I have some
builtin patterns, here, you can use them".

It's the same as all the vector intrinsics. Those don't hurt anybody -
as long as they only get used when people use the intrinsics. If the
compiler starts to suddenly use vector intrinsics without being told
to, *THAT* can be a problem. But there is never any reson to turn off
any particular intrinsic otherwise.

If you don't want it used, don't use it. And if you do use it, the
compiler generates the vector code sequence. It's that simple.

So to me, a compiler flag like "-fno-builtin-memcpy" is completely
insane. The flag adds absolutely no value.

The real value would be "-fno-magic-bcmp" which turns off stupid
optimizations that magically turn non-bcmp things into bcmp. But it
should not turn off *actual* __builtin_bcmp() if such a thing exists
and people want to explicitly use it.

             Linus