[v2] x86/build: don't build CONFIG_X86_32 as -ffreestanding

Commit Message

Kees Cook Feb. 3, 2022, 8:40 p.m. UTC

From: Nick Desaulniers <[e-mail]>

-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).

i386_defconfig build+boot tested with GCC and Clang. Removes a pretty
old TODO from the codebase.

[kees: These libcall optimizations are specifically needed to allow Clang
to correctly optimize the string functions under CONFIG_FORTIFY_SOURCE.]

Fixes: 6edfba1b33c7 ("x86_64: Don't define string functions to builtin")
Suggested-by: Arvind Sankar <[e-mail]>
Signed-off-by: Nick Desaulniers <[e-mail]>
Reviewed-by: Fangrui Song <[e-mail]>
Reviewed-by: Kees Cook <[e-mail]>
Signed-off-by: Kees Cook <[e-mail]>
Link: https://lore.kernel.org/r/[e-mail]
---
This solves build issues for Clang+FORTIFY, and aligns X86_32 with X86_64
builds again. x86 maintainers: I can carry this in my memcpy topic branch
unless you'd prefer to take it?
---
 arch/x86/Makefile | 3 ---
 1 file changed, 3 deletions(-)

Comments

Nick Desaulniers Feb. 3, 2022, 8:45 p.m. UTC | #1

On Thu, Feb 3, 2022 at 12:40 PM Kees Cook <[e-mail]> wrote:
>
> From: Nick Desaulniers <[e-mail]>
>
> -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.

While the bcmp shenanigans were ultimately resolved by
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
(and this popped up again in
commit 1e1b6d63d634 ("lib/string.c: implement stpcpy")
).  I'm still very much in favor of this patch, and should have
pursued it. Thanks for resending!

Patch

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index e84cdd409b64..7ef211865239 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -88,9 +88,6 @@  ifeq ($(CONFIG_X86_32),y)
         include $(srctree)/arch/x86/Makefile_32.cpu
         KBUILD_CFLAGS += $(cflags-y)
 
-        # temporary until string.h is fixed
-        KBUILD_CFLAGS += -ffreestanding
-
 	ifeq ($(CONFIG_STACKPROTECTOR),y)
 		ifeq ($(CONFIG_SMP),y)
 			KBUILD_CFLAGS += -mstack-protector-guard-reg=fs -mstack-protector-guard-symbol=__stack_chk_guard