public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.
--

             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