linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave@sr71.net>
To: linux-kernel@vger.kernel.org
Cc: dave@sr71.net, dave.hansen@linux.intel.com, x86@kernel.org,
	luto@kernel.org, fenghua.yu@intel.com, yu-cheng.yu@intel.com
Subject: [PATCH] x86, fpu: fix 32-bit signal frame handling
Date: Tue, 10 Nov 2015 16:23:54 -0800	[thread overview]
Message-ID: <20151111002354.A0799571@viggo.jf.intel.com> (raw)


From: Dave Hansen <dave.hansen@linux.intel.com>

(This should have gone to LKML originally. Sorry for the extra
 noise, folks on the cc.)

Background:

Signal frames on x86 have two formats:
1. For 32-bit executables (whether on a real 32-bit kernel or
   under ia32 emulation on a 64-bit kernel) we have a
  'fpregset_t' that includes the "FSAVE" registers.
2. For 64-bit executables (on 64-bit kernels obviously), the
   'fpregset_t' is smaller and does not contain the "FSAVE"
   state.

When creating the signal frame, we have to be aware of whether
we are running a 32 or 64-bit executable so we create the correct
format signal frame.

Problem:

save_xstate_epilog() uses 'fx_sw_reserved_ia32' whenever it is
called for a 32-bit executable.  This is for real 32-bit and
ia32 emulation.

But, fpu__init_prepare_fx_sw_frame() only initializes
'fx_sw_reserved_ia32' when emulation is enabled, *NOT* for real
32-bit kernels.

This leads to really wierd situations where 32-bit programs
lose their extended state when returning from a signal handler.
The kernel copies the uninitialized (zero) 'fx_sw_reserved_ia32'
out to userspace in save_xstate_epilog().  But when returning
from the signal, the kernel errors out in check_for_xstate()
when it does not see FP_XSTATE_MAGIC1 present (because it was
zeroed).  This leads to the FPU/XSAVE state being initialized.

For MPX, this leads to the most permissive state and means we
silently lose bounds violations.  I think this would also mean
that we could lose *ANY* FPU/SSE/AVX state.  I'm not sure why
no one has spotted this bug.

I believe this was broken by:

	72a671ced: x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels

way back in 2012.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: luto@kernel.org
Cc: fenghua.yu@intel.com
Cc: yu-cheng.yu@intel.com
---

 b/arch/x86/kernel/fpu/signal.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff -puN arch/x86/kernel/fpu/signal.c~only-fix-signal-bug arch/x86/kernel/fpu/signal.c
--- a/arch/x86/kernel/fpu/signal.c~only-fix-signal-bug	2015-11-10 14:30:19.910135621 -0800
+++ b/arch/x86/kernel/fpu/signal.c	2015-11-10 14:30:19.913135757 -0800
@@ -385,20 +385,19 @@ fpu__alloc_mathframe(unsigned long sp, i
  */
 void fpu__init_prepare_fx_sw_frame(void)
 {
-	int fsave_header_size = sizeof(struct fregs_state);
 	int size = xstate_size + FP_XSTATE_MAGIC2_SIZE;
 
-	if (config_enabled(CONFIG_X86_32))
-		size += fsave_header_size;
-
 	fx_sw_reserved.magic1 = FP_XSTATE_MAGIC1;
 	fx_sw_reserved.extended_size = size;
 	fx_sw_reserved.xfeatures = xfeatures_mask;
 	fx_sw_reserved.xstate_size = xstate_size;
 
-	if (config_enabled(CONFIG_IA32_EMULATION)) {
+	if (config_enabled(CONFIG_IA32_EMULATION) ||
+	    config_enabled(CONFIG_X86_32)) {
+		int fsave_header_size = sizeof(struct fregs_state);
+
 		fx_sw_reserved_ia32 = fx_sw_reserved;
-		fx_sw_reserved_ia32.extended_size += fsave_header_size;
+		fx_sw_reserved_ia32.extended_size = size + fsave_header_size;
 	}
 }
 
_

             reply	other threads:[~2015-11-11  0:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11  0:23 Dave Hansen [this message]
2015-11-12 13:28 ` [tip:x86/urgent] x86/fpu: Fix 32-bit signal frame handling tip-bot for Dave Hansen
2015-11-12 22:50 ` [PATCH] x86, fpu: fix " Dave Hansen
2015-11-27 10:06   ` Ingo Molnar

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=20151111002354.A0799571@viggo.jf.intel.com \
    --to=dave@sr71.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).