x86, fpu: fix 32-bit signal frame handling

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


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"

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.


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

This was broken by:

	commit 72a671ced66db6d1c2bfff1c930a101ac8d08204
	Author: Suresh Siddha <suresh.b.siddha@intel.com>
	Date:   Tue Jul 24 16:05:29 2012 -0700

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

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
1 file changed