linux.git/arch/x86/kernel/fpu, branch v5.14

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

x86/fpu: Mark init_fpstate __ro_after_init

2021-06-23T17:58:45+00:00

Nothing has to write into that state after init.

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

x86/fpu: Don't store PKRU in xstate in fpu_reset_fpstate()

2021-06-23T17:55:16+00:00

PKRU for a task is stored in task->thread.pkru when the task is scheduled
out. For 'current' the authoritative source of PKRU is the hardware.

fpu_reset_fpstate() has two callers:

  1) fpu__clear_user_states() for !FPU systems. For those PKRU is irrelevant

  2) fpu_flush_thread() which is invoked from flush_thread(). flush_thread()
     resets the hardware to the kernel restrictive default value.

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