x86/fpu: Fix 32-bit signal frame handling
x86/fpu: Fix 32-bit signal frame handling

(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 32-bit 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:

	72a671ced66d ("x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels")

way back in 2012.

Signed-off-by: Dave Hansen <71bcd3d88361b22cd828f9a350d19d8775f56d4e@linux.intel.com>
Cc: <4fbacc2fa0ffdbb11bf1ad6925b886ebd08dd15f@vger.kernel.org>
Cc: Andy Lutomirski <2cc0d0d76de2e6f37b92deeb83c85cb306fc5dc1@amacapital.net>
Cc: Borislav Petkov <0691a664b24b6f15b20cd5aee64b72271db08be1@alien8.de>
Cc: Brian Gerst <e60badcb99f652a0bcc15460d39f7ea12d6655ee@gmail.com>
Cc: Denys Vlasenko <50fbbd36fe0f9c8261d4a3c762c8c29ffb35e48f@redhat.com>
Cc: H. Peter Anvin <8a453bad9912ffe59bc0f0b8abe03df9be19379e@zytor.com>
Cc: Linus Torvalds <69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org>
Cc: Peter Zijlstra <3fddac958924aef220f202ca567388ddab3f14a8@infradead.org>
Cc: Thomas Gleixner <00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de>
Cc: bfcdf3e6ca6cef45543bfbb57509c92aec9a39fb@sr71.net
Cc: 94fe9a7ec8ff966c1952fe98e39b5ae3a7477695@intel.com
Cc: 0258cbd15551af162900472cd41bbac0f7440882@intel.com
Link: dea89e0528740cec349211260eb520194a0fcbb5@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <9dbbbf0688fedc85ad4da37637f1a64b8c718ee2@kernel.org>

KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs,KristFoundation/Programs