From: Borislav Petkov <bp@alien8.de>
To: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>, Michael Matz <matz@suse.de>,
Michal Hocko <mhocko@suse.cz>,
lkml <linux-kernel@vger.kernel.org>
Subject: [RFC] x86: Disable traditional FPU instructions too
Date: Mon, 27 Jan 2014 17:37:58 +0100 [thread overview]
Message-ID: <20140127163758.GC6839@pd.tnic> (raw)
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@suse.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@suse.cz>
Cc: Michael Matz <matz@suse.de>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Borislav Petkov <bp@suse.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.
--
next reply other threads:[~2014-01-27 16:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 16:37 Borislav Petkov [this message]
2014-01-27 16:41 ` [RFC] x86: Disable traditional FPU instructions too H. Peter Anvin
2014-01-27 16:43 ` Jiri Kosina
2014-01-27 17:01 ` Andi Kleen
2014-01-27 17:16 ` H. Peter Anvin
2014-01-27 17:24 ` Borislav Petkov
2014-01-27 16:45 ` Borislav Petkov
2014-01-28 9:37 ` Michal Hocko
2014-01-28 10:25 ` H. Peter Anvin
2014-01-28 10:33 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140127163758.GC6839@pd.tnic \
--to=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=matz@suse.de \
--cc=mhocko@suse.cz \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox