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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 6 Jan 2021 16:27:34 -0800
From:   Fangrui Song <>
To:     Nick Desaulniers <>
Cc:     Masahiro Yamada <>,
        Andrew Morton <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        Michal Marek <>,,,
        Kees Cook <>,
        Tony Luck <>,
        Dmitry Vyukov <>,
        Michael Ellerman <>,
        Joe Perches <>,
        Joel Fernandes <>,
        Daniel Axtens <>,
        Arvind Sankar <>,
        Andy Shevchenko <>,
        Alexandru Ardelean <>,
        Yury Norov <>,,
        "H . Peter Anvin" <>,
        Ard Biesheuvel <>,
        "Paul E . McKenney" <>,
        Daniel Kiper <>,
        Bruce Ashfield <>,
        Marco Elver <>,
        Vamshi K Sthambamkadi <>,
        Andi Kleen <>,
        Linus Torvalds <>,
        Dávid Bolvanský <>,
        Eli Friedman <>
Subject: Re: [PATCH 4/4] x86: don't build CONFIG_X86_32 as -ffreestanding

On 2020-08-17, 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.
>i386_defconfig build+boot tested with GCC and Clang. Removes a pretty
>old TODO from the codebase.
>Fixes: 6edfba1b33c7 ("x86_64: Don't define string functions to builtin")
>Suggested-by: Arvind Sankar <>
>Signed-off-by: Nick Desaulniers <>
>Reviewed-by: Kees Cook <>
> arch/x86/Makefile | 3 ---
> 1 file changed, 3 deletions(-)
>diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>index 4346ffb2e39f..2383a96cf4fd 100644
>--- a/arch/x86/Makefile
>+++ b/arch/x86/Makefile
>@@ -80,9 +80,6 @@ ifeq ($(CONFIG_X86_32),y)
>         # CPU-specific tuning. Anything which can be shared with UML should go here.
>         include arch/x86/Makefile_32.cpu
>         KBUILD_CFLAGS += $(cflags-y)
>-        # temporary until string.h is fixed
>-        KBUILD_CFLAGS += -ffreestanding
> else
>         BITS := 64
>         UTS_MACHINE := x86_64

Reviewed-by: Fangrui Song <>

But dropping -ffreestanding causes compiler produced declarations which
"x86: Treat R_386_PLT32 as R_386_PC32" as a prerequisite
to build with trunk Clang

Since there have been more than 4 months, it seems that something else
regressed the non -ffreestanding build. Maybe another -fno-builtin-* is
needed somewhere.

Powered by blists - more mailing lists