linux-kernel - [RFC] x86: Disable traditional FPU instructions too

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140127163758.GC6839@pd.tnic>
Date:	Mon, 27 Jan 2014 17:37:58 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	Jiri Kosina <jkosina@...e.cz>, Michael Matz <matz@...e.de>,
	Michal Hocko <mhocko@...e.cz>,
	lkml <linux-kernel@...r.kernel.org>
Subject: [RFC] x86: Disable traditional FPU instructions too

Hey guys,

should we do the below? It looks like we don't disable the generation of
*all* FPU instructions on x86_64 (commit message below has the rationale
why).

We do -msoft-float on 32-bit only and Micha says that -msoft-float and
-mno-80387 are the same and the gcc manpage says:

           On machines where a function returns floating-point results in the 80387
           register stack, some floating-point opcodes may be emitted even if
           -msoft-float is used.

and right after, it has also

       -mno-fp-ret-in-387
           Do not use the FPU registers for return values of functions.

           The usual calling convention has functions return values of types "float"
           and "double" in an FPU register, even if there is no FPU.  The idea is that
           the operating system should emulate an FPU.

           The option -mno-fp-ret-in-387 causes such values to be returned in ordinary
           CPU registers instead.

Btw, there's this -mno-fp-regs switch too which forces passing of FP
results of functions in integer registers...

So maybe we should do this:

---
From: Borislav Petkov <bp@...e.de>
Subject: [PATCH] x86: Disable generation of traditional x87 instructions

We recently had the case where wrongly used constant caused the
generation of x87 instructions in kernel code unknowingly, wreaking all
kinds of havoc. Disable the generation of those too. This will save
people a lot of time when trying to debug such issues by erroring out
of the build and not manifesting itself in all kinds of spectacular and
funny ways at runtime.

Cc: Jiri Kosina <jkosina@...e.cz>
Cc: Michael Matz <matz@...e.de>
Cc: Michal Hocko <mhocko@...e.cz>
Signed-off-by: Borislav Petkov <bp@...e.de>
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 13b22e0f681d..dbd31182669c 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -61,7 +61,7 @@ else
         KBUILD_CFLAGS += -m64
 
         # Don't autogenerate MMX or SSE instructions
-        KBUILD_CFLAGS += -mno-mmx -mno-sse
+        KBUILD_CFLAGS += -mno-mmx -mno-sse -mno-80387 -mno-fp-ret-in-387
 
 	# Use -mpreferred-stack-boundary=3 if supported.
 	KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3)
-- 
1.8.5.2.192.g7794a68


-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/