linux-stable.git/arch/x86/kernel/fpu, branch linux-5.14.y

x86/fpu: Mask out the invalid MXCSR bits properly

2021-10-20T09:57:50+00:00

commit b2381acd3fd9bacd2c63f53b2c610c89959b31cc upstream.

This is a fix for the fix (yeah, /facepalm).

The correct mask to use is not the negation of the MXCSR_MASK but the
actual mask which contains the supported bits in the MXCSR register.

Reported and debugged by Ville Syrjälä 

Fixes: d298b03506d3 ("x86/fpu: Restore the masking out of reserved MXCSR bits")
Signed-off-by: Borislav Petkov 
Tested-by: Ville Syrjälä 
Tested-by: Ser Olmy 
Cc: 
Link: https://lore.kernel.org/r/YWgYIYXLriayyezv@intel.com
Signed-off-by: Greg Kroah-Hartman

x86/fpu: Restore the masking out of reserved MXCSR bits

2021-10-13T07:42:03+00:00

commit d298b03506d3e161f7492c440babb0bfae35e650 upstream.

Ser Olmy reported a boot failure:

  init[1] bad frame in sigreturn frame:(ptrval) ip:b7c9fbe6 sp:bf933310 orax:ffffffff \
	  in libc-2.33.so[b7bed000+156000]
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
  CPU: 0 PID: 1 Comm: init Tainted: G        W         5.14.9 #1
  Hardware name: Hewlett-Packard HP PC/HP Board, BIOS  JD.00.06 12/06/2001
  Call Trace:
   dump_stack_lvl
   dump_stack
   panic
   do_exit.cold
   do_group_exit
   get_signal
   arch_do_signal_or_restart
   ? force_sig_info_to_task
   ? force_sig
   exit_to_user_mode_prepare
   syscall_exit_to_user_mode
   do_int80_syscall_32
   entry_INT80_32

on an old 32-bit Intel CPU:

  vendor_id       : GenuineIntel
  cpu family      : 6
  model           : 6
  model name      : Celeron (Mendocino)
  stepping        : 5
  microcode       : 0x3

Ser bisected the problem to the commit in Fixes.

tglx suggested reverting the rejection of invalid MXCSR values which
this commit introduced and replacing it with what the old code did -
simply masking them out to zero.

Further debugging confirmed his suggestion:

  fpu->state.fxsave.mxcsr: 0xb7be13b4, mxcsr_feature_mask: 0xffbf
  WARNING: CPU: 0 PID: 1 at arch/x86/kernel/fpu/signal.c:384 __fpu_restore_sig+0x51f/0x540

so restore the original behavior only for 32-bit kernels where you have
ancient machines with buggy hardware. For 32-bit programs on 64-bit
kernels, user space which supplies wrong MXCSR values is considered
malicious so fail the sigframe restoration there.

Fixes: 6f9866a166cd ("x86/fpu/signal: Let xrstor handle the features to init")
Reported-by: Ser Olmy 
Signed-off-by: Borislav Petkov 
Tested-by: Ser Olmy 
Cc: 
Link: https://lkml.kernel.org/r/YVtA67jImg3KlBTw@zn.tnic
Signed-off-by: Greg Kroah-Hartman

x86/fpu/xstate: Clear xstate header in copy_xstate_to_uabi_buf() again

2021-06-24T15:19:51+00:00

The change which made copy_xstate_to_uabi_buf() usable for
[x]fpregs_get() removed the zeroing of the header which means the
header, which is copied to user space later, contains except for the
xfeatures member, random stack content.

Add the memset() back to zero it before usage.

Fixes: eb6f51723f03 ("x86/fpu: Make copy_xstate_to_kernel() usable for [x]fpregs_get()")
Reported-by: kernel test robot 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/875yy3wb8h.ffs@nanos.tec.linutronix.de

x86/fpu/signal: Let xrstor handle the features to init

2021-06-23T21:45:31+00:00

There is no reason to do an extra XRSTOR from init_fpstate for feature
bits which have been cleared by user space in the FX magic xfeatures
storage.

Just clear them in the task's XSTATE header and do a full restore which
will put these cleared features into init state.

There is no real difference in performance because the current code
already does a full restore when the xfeatures bits are preserved as the
signal frame setup has stored them, which is the full UABI feature set.

 [ bp: Use the negated mxcsr_feature_mask in the MXCSR check. ]

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.804115017@linutronix.de

x86/fpu/signal: Handle #PF in the direct restore path

2021-06-23T18:05:33+00:00

If *RSTOR raises an exception, then the slow path is taken. That's wrong
because if the reason was not #PF then going through the slow path is waste
of time because that will end up with the same conclusion that the data is
invalid.

Now that the wrapper around *RSTOR return an negative error code, which is
the negated trap number, it's possible to differentiate.

If the *RSTOR raised #PF then handle it directly in the fast path and if it
was some other exception, e.g. #GP, then give up and do not try the fast
path.

This removes the legacy frame FRSTOR code from the slow path because FRSTOR
is not a ia32_fxstate frame and is therefore handled in the fast path.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.696022863@linutronix.de

x86/fpu/signal: Split out the direct restore code

2021-06-23T18:03:44+00:00

Prepare for smarter failure handling of the direct restore.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.493455414@linutronix.de

x86/fpu/signal: Sanitize copy_user_to_fpregs_zeroing()

2021-06-23T18:03:15+00:00

Now that user_xfeatures is correctly set when xsave is enabled, remove
the duplicated initialization of components.

Rename the function while at it.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.377341297@linutronix.de

x86/fpu/signal: Sanitize the xstate check on sigframe

2021-06-23T18:02:46+00:00

Utilize the check for the extended state magic in the FX software reserved
bytes and set the parameters for restoring fx_only in the relevant members
of fw_sw_user.

This allows further cleanups on top because the data is consistent.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.277738268@linutronix.de

x86/fpu/signal: Remove the legacy alignment check

2021-06-23T18:01:55+00:00

Checking for the XSTATE buffer being 64-byte aligned, and if not,
deciding just to restore the FXSR state is daft.

If user space provides an unaligned math frame and has the extended state
magic set in the FX software reserved bytes, then it really can keep the
pieces.

If the frame is unaligned and the FX software magic is not set, then
fx_only is already set and the restore will use fxrstor.

Remove it.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.184149902@linutronix.de

x86/fpu/signal: Move initial checks into fpu__restore_sig()

2021-06-23T17:59:57+00:00

__fpu__restore_sig() is convoluted and some of the basic checks can
trivially be done in the calling function as well as the final error
handling of clearing user state.

 [ bp: Fixup typos. ]

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20210623121457.086336154@linutronix.de