x86, fpu: fix 32-bit signal frame handling

From: Dave Hansen <[email protected]>

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

---

 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
@@ -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;
 	}
 }
 

_

FWIW, I looked at this a little more today.

We lose all extended state for our "extended xfeatures", also known as state component numbers >=2 (AVX, MPX, AVX-512, PKEYs)... But we retain the state for FP/SSE state. So we lose the top half of the AVX registers (the bottom half are SSE state).

I also did a little objdump'ing and grep'ing in a 32-bit distro. There's no sign of actual use of the ymm registers.

Basically, it appears nobody has taken a 64-bit Sandybridge or later CPU, put a 32-bit distro on it that had a >=3.7 kernel on it and tried to use AVX instructions. Or, if they did, they got random corruption and gave up before actually diagnosing the problem. :)

Weird: putting a 32-bit distro on such a fine piece of 64-bit hardware is pure masochism - and such masochism would also imply the willingness to track down random corruptions! ;-)

Thanks,

Ingo