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: <fae91af3-4e08-a929-e5c3-25271ad7324b@zytor.com>
Date:   Mon, 17 Aug 2020 15:44:31 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Nick Desaulniers <ndesaulniers@...gle.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>
Cc:     Michal Marek <michal.lkml@...kovi.net>,
        linux-kbuild@...r.kernel.org, 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>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        Yury Norov <yury.norov@...il.com>, 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>,
        Andi Kleen <ak@...e.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dávid Bolvanský <david.bolvansky@...il.com>,
        Eli Friedman <efriedma@...cinc.com>
Subject: Re: [PATCH 0/4] -ffreestanding/-fno-builtin-* patches

On 2020-08-17 15:02, Nick Desaulniers wrote:
> -ffreestanding typically inhibits "libcall optimizations" where calls to
> certain library functions can be replaced by the compiler in certain
> cases to calls to other library functions that may be more efficient.
> This can be problematic for embedded targets that don't provide full
> libc implementations.
> 
> -ffreestanding inhibits all such optimizations, which is the safe
> choice, but generally we want the optimizations that are performed. The
> Linux kernel does implement a fair amount of libc routines. Instead of
> -ffreestanding (which makes more sense in smaller images like kexec's
> purgatory image), prefer -fno-builtin-* flags to disable the compiler
> from emitting calls to functions which may not be defined.
> 
> If you see a linkage failure due to a missing symbol that's typically
> defined in a libc, and not explicitly called from the source code, then
> the compiler may have done such a transform.  You can either implement
> such a function (ie. in lib/string.c) or disable the transform outright
> via -fno-builtin-* flag (where * is the name of the library routine, ie.
> -fno-builtin-bcmp).
> 

This is arguably exactly the wrong way around.

The way this *should* be done is by opt-in, not opt-out, which by almost
definition ends up being a game of whack-a-mole, like in this case
stpcpy(). Furthermore, it is unlikely that people will remember what
options to flip when and if stpcpy() happens to be implemented in the
kernel.

The problem here is twofold:

1. The user would be expected to know what kind of the optimizations the
compiler can do on what function, which is private knowledge to the
compiler.

2. The only way to override -fno-builtin is by a header file with macros
overriding the function names with __builtin, but that doesn't tell the
compiler proper anything about the execution environment.

So the Right Thing is for the compiler authors to change the way
-ffreestanding works.  -ffreestanding means, by definition, that there
are no library calls (other than libgcc or whatever else is supplied
with the compiler) that the compiler can call. That is currently an
all-or-nothing choice, or at least one choice per C standard implemented.

Instead, a compile job with -ffreestanding should be able to provide a
list of standard C functions that the compiler may call, and thus the
compiler actually can do the right thing depending on which exact
functions it would consider calling. This list is probably most easily
supplied in the form of a header file with #pragma directives.

	-hpa