2019-05-19 13:08:55 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 1994 Linus Torvalds
|
|
|
|
*
|
|
|
|
* Pentium III FXSR, SSE support
|
|
|
|
* General FPU state handling cleanups
|
|
|
|
* Gareth Hughes <gareth@valinux.com>, May 2000
|
|
|
|
*/
|
2021-10-15 03:16:39 +02:00
|
|
|
#include <asm/fpu/api.h>
|
2015-04-30 08:53:18 +02:00
|
|
|
#include <asm/fpu/regset.h>
|
2021-10-15 03:16:20 +02:00
|
|
|
#include <asm/fpu/sched.h>
|
2015-04-30 08:45:02 +02:00
|
|
|
#include <asm/fpu/signal.h>
|
2016-07-11 09:18:56 -07:00
|
|
|
#include <asm/fpu/types.h>
|
2025-04-30 22:42:41 -07:00
|
|
|
#include <asm/msr.h>
|
2015-04-30 09:29:38 +02:00
|
|
|
#include <asm/traps.h>
|
2018-07-29 12:15:33 +02:00
|
|
|
#include <asm/irq_regs.h>
|
2015-04-30 08:45:02 +02:00
|
|
|
|
2022-05-04 00:12:19 +00:00
|
|
|
#include <uapi/asm/kvm.h>
|
|
|
|
|
2015-04-26 16:57:55 +02:00
|
|
|
#include <linux/hardirq.h>
|
x86/pkeys: Default to a restrictive init PKRU
PKRU is the register that lets you disallow writes or all access to a given
protection key.
The XSAVE hardware defines an "init state" of 0 for PKRU: its most
permissive state, allowing access/writes to everything. Since we start off
all new processes with the init state, we start all processes off with the
most permissive possible PKRU.
This is unfortunate. If a thread is clone()'d [1] before a program has
time to set PKRU to a restrictive value, that thread will be able to write
to all data, no matter what pkey is set on it. This weakens any integrity
guarantees that we want pkeys to provide.
To fix this, we define a very restrictive PKRU to override the
XSAVE-provided value when we create a new FPU context. We choose a value
that only allows access to pkey 0, which is as restrictive as we can
practically make it.
This does not cause any practical problems with applications using
protection keys because we require them to specify initial permissions for
each key when it is allocated, which override the restrictive default.
In the end, this ensures that threads which do not know how to manage their
own pkey rights can not do damage to data which is pkey-protected.
I would have thought this was a pretty contrived scenario, except that I
heard a bug report from an MPX user who was creating threads in some very
early code before main(). It may be crazy, but folks evidently _do_ it.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-arch@vger.kernel.org
Cc: Dave Hansen <dave@sr71.net>
Cc: mgorman@techsingularity.net
Cc: arnd@arndb.de
Cc: linux-api@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: luto@kernel.org
Cc: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/20160729163021.F3C25D4A@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-07-29 09:30:21 -07:00
|
|
|
#include <linux/pkeys.h>
|
2021-10-25 15:04:13 +11:00
|
|
|
#include <linux/vmalloc.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-10-15 03:16:30 +02:00
|
|
|
#include "context.h"
|
2021-10-15 03:16:21 +02:00
|
|
|
#include "internal.h"
|
2021-10-15 03:16:26 +02:00
|
|
|
#include "legacy.h"
|
2021-10-15 03:16:07 +02:00
|
|
|
#include "xstate.h"
|
|
|
|
|
2016-06-01 10:42:20 -07:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <asm/trace/fpu.h>
|
|
|
|
|
2021-10-21 15:55:11 -07:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
DEFINE_STATIC_KEY_FALSE(__fpu_state_size_dynamic);
|
2021-10-21 15:55:18 -07:00
|
|
|
DEFINE_PER_CPU(u64, xfd_state);
|
2021-10-21 15:55:11 -07:00
|
|
|
#endif
|
|
|
|
|
2021-10-15 01:09:29 +02:00
|
|
|
/* The FPU state configuration data for kernel and user space */
|
|
|
|
struct fpu_state_config fpu_kernel_cfg __ro_after_init;
|
|
|
|
struct fpu_state_config fpu_user_cfg __ro_after_init;
|
x86/fpu/xstate: Differentiate default features for host and guest FPUs
Currently, guest and host FPUs share the same default features. However,
the CET supervisor xstate is the first feature that needs to be enabled
exclusively for guest FPUs. Enabling it for host FPUs leads to a waste of
24 bytes in the XSAVE buffer.
To support "guest-only" features, add a new structure to hold the
default features and sizes for guest FPUs to clearly differentiate them
from those for host FPUs.
Add two helpers to provide the default feature masks for guest and host
FPUs. Default features are derived by applying the masks to the maximum
supported features.
Note that,
1) for now, guest_default_mask() and host_default_mask() are identical.
This will change in a follow-up patch once guest permissions, default
xfeatures, and fpstate size are all converted to use the guest defaults.
2) only supervisor features will diverge between guest FPUs and host
FPUs, while user features will remain the same [1][2]. So, the new
vcpu_fpu_config struct does not include default user features and size
for the UABI buffer.
An alternative approach is adding a guest_only_xfeatures member to
fpu_kernel_cfg and adding two helper functions to calculate the guest
default xfeatures and size. However, calculating these defaults at runtime
would introduce unnecessary overhead.
Suggested-by: Chang S. Bae <chang.seok.bae@intel.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: John Allen <john.allen@amd.com>
Link: https://lore.kernel.org/kvm/aAwdQ759Y6V7SGhv@google.com/ [1]
Link: https://lore.kernel.org/kvm/9ca17e1169805f35168eb722734fbf3579187886.camel@intel.com/ [2]
Link: https://lore.kernel.org/all/20250522151031.426788-2-chao.gao%40intel.com
2025-05-22 08:10:04 -07:00
|
|
|
struct vcpu_fpu_config guest_default_cfg __ro_after_init;
|
2021-10-15 01:09:29 +02:00
|
|
|
|
2015-04-30 11:07:06 +02:00
|
|
|
/*
|
|
|
|
* Represents the initial FPU state. It's mostly (but not completely) zeroes,
|
|
|
|
* depending on the FPU hardware format:
|
|
|
|
*/
|
2021-10-13 16:55:28 +02:00
|
|
|
struct fpstate init_fpstate __ro_after_init;
|
2015-04-30 11:07:06 +02:00
|
|
|
|
2025-05-18 12:32:12 -07:00
|
|
|
/*
|
|
|
|
* Track FPU initialization and kernel-mode usage. 'true' means the FPU is
|
|
|
|
* initialized and is not currently being used by the kernel:
|
|
|
|
*/
|
|
|
|
DEFINE_PER_CPU(bool, kernel_fpu_allowed);
|
2015-01-15 20:19:43 +01:00
|
|
|
|
2015-04-23 12:13:04 +02:00
|
|
|
/*
|
2015-04-23 12:18:28 +02:00
|
|
|
* Track which context is using the FPU on the CPU:
|
2015-04-23 12:13:04 +02:00
|
|
|
*/
|
2015-04-23 12:18:28 +02:00
|
|
|
DEFINE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
|
2015-04-23 12:13:04 +02:00
|
|
|
|
2025-04-09 23:11:26 +02:00
|
|
|
#ifdef CONFIG_X86_DEBUG_FPU
|
|
|
|
struct fpu *x86_task_fpu(struct task_struct *task)
|
|
|
|
{
|
|
|
|
if (WARN_ON_ONCE(task->flags & PF_KTHREAD))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return (void *)task + sizeof(*task);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2012-02-21 10:25:45 -08:00
|
|
|
/*
|
|
|
|
* Can we use the FPU in kernel mode with the
|
|
|
|
* whole "kernel_fpu_begin/end()" sequence?
|
|
|
|
*/
|
|
|
|
bool irq_fpu_usable(void)
|
|
|
|
{
|
2022-05-01 21:31:43 +02:00
|
|
|
if (WARN_ON_ONCE(in_nmi()))
|
|
|
|
return false;
|
|
|
|
|
x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs
Background:
===========
Currently kernel-mode FPU is not always usable in softirq context on
x86, since softirqs can nest inside a kernel-mode FPU section in task
context, and nested use of kernel-mode FPU is not supported.
Therefore, x86 SIMD-optimized code that can be called in softirq context
has to sometimes fall back to non-SIMD code. There are two options for
the fallback, both of which are pretty terrible:
(a) Use a scalar fallback. This can be 10-100x slower than vectorized
code because it cannot use specialized instructions like AES, SHA,
or carryless multiplication.
(b) Execute the request asynchronously using a kworker. In other
words, use the "crypto SIMD helper" in crypto/simd.c.
Currently most of the x86 en/decryption code (skcipher and aead
algorithms) uses option (b), since this avoids the slow scalar fallback
and it is easier to wire up. But option (b) is still really bad for its
own reasons:
- Punting the request to a kworker is bad for performance too.
- It forces the algorithm to be marked as asynchronous
(CRYPTO_ALG_ASYNC), preventing it from being used by crypto API
users who request a synchronous algorithm. That's another huge
performance problem, which is especially unfortunate for users who
don't even do en/decryption in softirq context.
- It makes all en/decryption operations take a detour through
crypto/simd.c. That involves additional checks and an additional
indirect call, which slow down en/decryption for *everyone*.
Fortunately, the skcipher and aead APIs are only usable in task and
softirq context in the first place. Thus, if kernel-mode FPU were to be
reliably usable in softirq context, no fallback would be needed.
Indeed, other architectures such as arm, arm64, and riscv have already
done this.
Changes implemented:
====================
Therefore, this patch updates x86 accordingly to reliably support
kernel-mode FPU in softirqs.
This is done by just disabling softirq processing in kernel-mode FPU
sections (when hardirqs are not already disabled), as that prevents the
nesting that was problematic.
This will delay some softirqs slightly, but only ones that would have
otherwise been nested inside a task context kernel-mode FPU section.
Any such softirqs would have taken the slow fallback path before if they
tried to do any en/decryption. Now these softirqs will just run at the
end of the task context kernel-mode FPU section (since local_bh_enable()
runs pending softirqs) and will no longer take the slow fallback path.
Alternatives considered:
========================
- Make kernel-mode FPU sections fully preemptible. This would require
growing task_struct by another struct fpstate which is more than 2K.
- Make softirqs save/restore the kernel-mode FPU state to a per-CPU
struct fpstate when nested use is detected. Somewhat interesting, but
seems unnecessary when a simpler solution exists.
Performance results:
====================
I did some benchmarks with AES-XTS encryption of 16-byte messages (which is
unrealistically small, but this makes it easier to see the overhead of
kernel-mode FPU...). The baseline was 384 MB/s. Removing the use of
crypto/simd.c, which this work makes possible, increases it to 487 MB/s,
a +27% improvement in throughput.
CPU was AMD Ryzen 9 9950X (Zen 5). No debugging options were enabled.
[ mingo: Prettified the changelog and added performance results. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>
Link: https://lore.kernel.org/r/20250304204954.3901-1-ebiggers@kernel.org
2025-03-04 12:49:54 -08:00
|
|
|
/*
|
2025-05-18 12:32:12 -07:00
|
|
|
* Return false in the following cases:
|
|
|
|
*
|
|
|
|
* - FPU is not yet initialized. This can happen only when the call is
|
|
|
|
* coming from CPU onlining, for example for microcode checksumming.
|
|
|
|
* - The kernel is already using the FPU, either because of explicit
|
|
|
|
* nesting (which should never be done), or because of implicit
|
|
|
|
* nesting when a hardirq interrupted a kernel-mode FPU section.
|
|
|
|
*
|
|
|
|
* The single boolean check below handles both cases:
|
x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs
Background:
===========
Currently kernel-mode FPU is not always usable in softirq context on
x86, since softirqs can nest inside a kernel-mode FPU section in task
context, and nested use of kernel-mode FPU is not supported.
Therefore, x86 SIMD-optimized code that can be called in softirq context
has to sometimes fall back to non-SIMD code. There are two options for
the fallback, both of which are pretty terrible:
(a) Use a scalar fallback. This can be 10-100x slower than vectorized
code because it cannot use specialized instructions like AES, SHA,
or carryless multiplication.
(b) Execute the request asynchronously using a kworker. In other
words, use the "crypto SIMD helper" in crypto/simd.c.
Currently most of the x86 en/decryption code (skcipher and aead
algorithms) uses option (b), since this avoids the slow scalar fallback
and it is easier to wire up. But option (b) is still really bad for its
own reasons:
- Punting the request to a kworker is bad for performance too.
- It forces the algorithm to be marked as asynchronous
(CRYPTO_ALG_ASYNC), preventing it from being used by crypto API
users who request a synchronous algorithm. That's another huge
performance problem, which is especially unfortunate for users who
don't even do en/decryption in softirq context.
- It makes all en/decryption operations take a detour through
crypto/simd.c. That involves additional checks and an additional
indirect call, which slow down en/decryption for *everyone*.
Fortunately, the skcipher and aead APIs are only usable in task and
softirq context in the first place. Thus, if kernel-mode FPU were to be
reliably usable in softirq context, no fallback would be needed.
Indeed, other architectures such as arm, arm64, and riscv have already
done this.
Changes implemented:
====================
Therefore, this patch updates x86 accordingly to reliably support
kernel-mode FPU in softirqs.
This is done by just disabling softirq processing in kernel-mode FPU
sections (when hardirqs are not already disabled), as that prevents the
nesting that was problematic.
This will delay some softirqs slightly, but only ones that would have
otherwise been nested inside a task context kernel-mode FPU section.
Any such softirqs would have taken the slow fallback path before if they
tried to do any en/decryption. Now these softirqs will just run at the
end of the task context kernel-mode FPU section (since local_bh_enable()
runs pending softirqs) and will no longer take the slow fallback path.
Alternatives considered:
========================
- Make kernel-mode FPU sections fully preemptible. This would require
growing task_struct by another struct fpstate which is more than 2K.
- Make softirqs save/restore the kernel-mode FPU state to a per-CPU
struct fpstate when nested use is detected. Somewhat interesting, but
seems unnecessary when a simpler solution exists.
Performance results:
====================
I did some benchmarks with AES-XTS encryption of 16-byte messages (which is
unrealistically small, but this makes it easier to see the overhead of
kernel-mode FPU...). The baseline was 384 MB/s. Removing the use of
crypto/simd.c, which this work makes possible, increases it to 487 MB/s,
a +27% improvement in throughput.
CPU was AMD Ryzen 9 9950X (Zen 5). No debugging options were enabled.
[ mingo: Prettified the changelog and added performance results. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>
Link: https://lore.kernel.org/r/20250304204954.3901-1-ebiggers@kernel.org
2025-03-04 12:49:54 -08:00
|
|
|
*/
|
2025-05-18 12:32:12 -07:00
|
|
|
if (!this_cpu_read(kernel_fpu_allowed))
|
2022-05-01 21:31:43 +02:00
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When not in NMI or hard interrupt context, FPU can be used in:
|
|
|
|
*
|
|
|
|
* - Task context except from within fpregs_lock()'ed critical
|
|
|
|
* regions.
|
|
|
|
*
|
|
|
|
* - Soft interrupt processing context which cannot happen
|
|
|
|
* while in a fpregs_lock()'ed critical region.
|
|
|
|
*/
|
|
|
|
if (!in_hardirq())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In hard interrupt context it's safe when soft interrupts
|
|
|
|
* are enabled, which means the interrupt did not hit in
|
|
|
|
* a fpregs_lock()'ed critical region.
|
|
|
|
*/
|
|
|
|
return !softirq_count();
|
2012-02-21 10:25:45 -08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(irq_fpu_usable);
|
|
|
|
|
2021-11-16 17:14:21 +01:00
|
|
|
/*
|
|
|
|
* Track AVX512 state use because it is known to slow the max clock
|
|
|
|
* speed of the core.
|
|
|
|
*/
|
|
|
|
static void update_avx_timestamp(struct fpu *fpu)
|
|
|
|
{
|
|
|
|
|
|
|
|
#define AVX512_TRACKING_MASK (XFEATURE_MASK_ZMM_Hi256 | XFEATURE_MASK_Hi16_ZMM)
|
|
|
|
|
|
|
|
if (fpu->fpstate->regs.xsave.header.xfeatures & AVX512_TRACKING_MASK)
|
|
|
|
fpu->avx512_timestamp = jiffies;
|
|
|
|
}
|
|
|
|
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
/*
|
2021-10-13 16:55:39 +02:00
|
|
|
* Save the FPU register state in fpu->fpstate->regs. The register state is
|
2021-06-23 14:02:00 +02:00
|
|
|
* preserved.
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
*
|
2021-06-23 14:02:00 +02:00
|
|
|
* Must be called with fpregs_lock() held.
|
|
|
|
*
|
|
|
|
* The legacy FNSAVE instruction clears all FPU state unconditionally, so
|
|
|
|
* register state has to be reloaded. That might be a pointless exercise
|
|
|
|
* when the FPU is going to be used by another task right after that. But
|
|
|
|
* this only affects 20+ years old 32bit systems and avoids conditionals all
|
|
|
|
* over the place.
|
|
|
|
*
|
|
|
|
* FXSAVE and all XSAVE variants preserve the FPU register state.
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
*/
|
2021-06-23 14:02:00 +02:00
|
|
|
void save_fpregs_to_fpstate(struct fpu *fpu)
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
{
|
|
|
|
if (likely(use_xsave())) {
|
2021-10-13 16:55:49 +02:00
|
|
|
os_xsave(fpu->fpstate);
|
2021-11-16 17:14:21 +01:00
|
|
|
update_avx_timestamp(fpu);
|
2021-06-23 14:02:00 +02:00
|
|
|
return;
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (likely(use_fxsr())) {
|
2021-10-13 16:55:39 +02:00
|
|
|
fxsave(&fpu->fpstate->regs.fxsave);
|
2021-06-23 14:02:00 +02:00
|
|
|
return;
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Legacy FPU register saving, FNSAVE always clears FPU registers,
|
2021-06-23 14:02:00 +02:00
|
|
|
* so we have to reload them from the memory state.
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
*/
|
2021-10-13 16:55:39 +02:00
|
|
|
asm volatile("fnsave %[fp]; fwait" : [fp] "=m" (fpu->fpstate->regs.fsave));
|
|
|
|
frstor(&fpu->fpstate->regs.fsave);
|
x86/fpu: Use proper mask to replace full instruction mask
When saving xstate to a kernel/user XSAVE area with the XSAVE family of
instructions, the current code applies the 'full' instruction mask (-1),
which tries to XSAVE all possible features. This method relies on
hardware to trim 'all possible' down to what is enabled in the
hardware. The code works well for now. However, there will be a
problem, if some features are enabled in hardware, but are not suitable
to be saved into all kernel XSAVE buffers, like task->fpu, due to
performance consideration.
One such example is the Last Branch Records (LBR) state. The LBR state
only contains valuable information when LBR is explicitly enabled by
the perf subsystem, and the size of an LBR state is large (808 bytes
for now). To avoid both CPU overhead and space overhead at each context
switch, the LBR state should not be saved into task->fpu like other
state components. It should be saved/restored on demand when LBR is
enabled in the perf subsystem. Current copy_xregs_to_* will trigger a
buffer overflow for such cases.
Three sites use the '-1' instruction mask which must be updated.
Two are saving/restoring the xstate to/from a kernel-allocated XSAVE
buffer and can use 'xfeatures_mask_all', which will save/restore all of
the features present in a normal task FPU buffer.
The last one saves the register state directly to a user buffer. It
could
also use 'xfeatures_mask_all'. Just as it was with the '-1' argument,
any supervisor states in the mask will be filtered out by the hardware
and not saved to the buffer. But, to be more explicit about what is
expected to be saved, use xfeatures_mask_user() for the instruction
mask.
KVM includes the header file fpu/internal.h. To avoid 'undefined
xfeatures_mask_all' compiling issue, move copy_fpregs_to_fpstate() to
fpu/core.c and export it, because:
- The xfeatures_mask_all is indirectly used via copy_fpregs_to_fpstate()
by KVM. The function which is directly used by other modules should be
exported.
- The copy_fpregs_to_fpstate() is a function, while xfeatures_mask_all
is a variable for the "internal" FPU state. It's safer to export a
function than a variable, which may be implicitly changed by others.
- The copy_fpregs_to_fpstate() is a big function with many checks. The
removal of the inline keyword should not impact the performance.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Link: https://lkml.kernel.org/r/1593780569-62993-20-git-send-email-kan.liang@linux.intel.com
2020-07-03 05:49:25 -07:00
|
|
|
}
|
|
|
|
|
2021-10-13 16:55:30 +02:00
|
|
|
void restore_fpregs_from_fpstate(struct fpstate *fpstate, u64 mask)
|
2021-06-23 14:02:15 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* AMD K7/K8 and later CPUs up to Zen don't save/restore
|
|
|
|
* FDP/FIP/FOP unless an exception is pending. Clear the x87 state
|
|
|
|
* here by setting it to fixed values. "m" is a random variable
|
|
|
|
* that should be in L1.
|
|
|
|
*/
|
|
|
|
if (unlikely(static_cpu_has_bug(X86_BUG_FXSAVE_LEAK))) {
|
|
|
|
asm volatile(
|
|
|
|
"fnclex\n\t"
|
|
|
|
"emms\n\t"
|
2024-03-15 09:18:23 +01:00
|
|
|
"fildl %[addr]" /* set F?P to defined value */
|
|
|
|
: : [addr] "m" (*fpstate));
|
2021-06-23 14:02:15 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (use_xsave()) {
|
2021-10-21 15:55:20 -07:00
|
|
|
/*
|
|
|
|
* Dynamically enabled features are enabled in XCR0, but
|
|
|
|
* usage requires also that the corresponding bits in XFD
|
|
|
|
* are cleared. If the bits are set then using a related
|
|
|
|
* instruction will raise #NM. This allows to do the
|
|
|
|
* allocation of the larger FPU buffer lazy from #NM or if
|
|
|
|
* the task has no permission to kill it which would happen
|
|
|
|
* via #UD if the feature is disabled in XCR0.
|
|
|
|
*
|
|
|
|
* XFD state is following the same life time rules as
|
|
|
|
* XSTATE and to restore state correctly XFD has to be
|
|
|
|
* updated before XRSTORS otherwise the component would
|
|
|
|
* stay in or go into init state even if the bits are set
|
|
|
|
* in fpstate::regs::xsave::xfeatures.
|
|
|
|
*/
|
|
|
|
xfd_update_state(fpstate);
|
|
|
|
|
2021-10-15 01:09:38 +02:00
|
|
|
/*
|
|
|
|
* Restoring state always needs to modify all features
|
|
|
|
* which are in @mask even if the current task cannot use
|
|
|
|
* extended features.
|
|
|
|
*
|
|
|
|
* So fpstate->xfeatures cannot be used here, because then
|
|
|
|
* a feature for which the task has no permission but was
|
|
|
|
* used by the previous task would not go into init state.
|
|
|
|
*/
|
|
|
|
mask = fpu_kernel_cfg.max_features & mask;
|
|
|
|
|
2021-10-21 15:55:19 -07:00
|
|
|
os_xrstor(fpstate, mask);
|
2021-06-23 14:02:15 +02:00
|
|
|
} else {
|
|
|
|
if (use_fxsr())
|
2021-10-13 16:55:30 +02:00
|
|
|
fxrstor(&fpstate->regs.fxsave);
|
2021-06-23 14:02:15 +02:00
|
|
|
else
|
2021-10-13 16:55:30 +02:00
|
|
|
frstor(&fpstate->regs.fsave);
|
2021-06-23 14:02:15 +02:00
|
|
|
}
|
|
|
|
}
|
2021-10-15 03:16:12 +02:00
|
|
|
|
2021-10-15 03:16:41 +02:00
|
|
|
void fpu_reset_from_exception_fixup(void)
|
|
|
|
{
|
2021-10-15 01:09:38 +02:00
|
|
|
restore_fpregs_from_fpstate(&init_fpstate, XFEATURE_MASK_FPSTATE);
|
2021-10-15 03:16:41 +02:00
|
|
|
}
|
|
|
|
|
2021-10-15 03:16:12 +02:00
|
|
|
#if IS_ENABLED(CONFIG_KVM)
|
2025-05-22 08:10:07 -07:00
|
|
|
static void __fpstate_reset(struct fpstate *fpstate);
|
2021-10-22 20:55:51 +02:00
|
|
|
|
2025-05-06 17:36:07 +08:00
|
|
|
static void fpu_lock_guest_permissions(void)
|
2022-01-05 04:35:13 -08:00
|
|
|
{
|
|
|
|
struct fpu_state_perm *fpuperm;
|
|
|
|
u64 perm;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_X86_64))
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock_irq(¤t->sighand->siglock);
|
2025-04-09 23:11:21 +02:00
|
|
|
fpuperm = &x86_task_fpu(current->group_leader)->guest_perm;
|
2022-01-05 04:35:13 -08:00
|
|
|
perm = fpuperm->__state_perm;
|
|
|
|
|
|
|
|
/* First fpstate allocation locks down permissions. */
|
|
|
|
WRITE_ONCE(fpuperm->__state_perm, perm | FPU_GUEST_PERM_LOCKED);
|
|
|
|
|
|
|
|
spin_unlock_irq(¤t->sighand->siglock);
|
|
|
|
}
|
2021-10-22 20:55:51 +02:00
|
|
|
|
|
|
|
bool fpu_alloc_guest_fpstate(struct fpu_guest *gfpu)
|
|
|
|
{
|
|
|
|
struct fpstate *fpstate;
|
|
|
|
unsigned int size;
|
|
|
|
|
2025-05-22 08:10:06 -07:00
|
|
|
size = guest_default_cfg.size + ALIGN(offsetof(struct fpstate, regs), 64);
|
|
|
|
|
2021-10-22 20:55:51 +02:00
|
|
|
fpstate = vzalloc(size);
|
|
|
|
if (!fpstate)
|
|
|
|
return false;
|
|
|
|
|
2025-05-22 08:10:06 -07:00
|
|
|
/* Initialize indicators to reflect properties of the fpstate */
|
|
|
|
fpstate->is_valloc = true;
|
|
|
|
fpstate->is_guest = true;
|
|
|
|
|
2025-05-22 08:10:07 -07:00
|
|
|
__fpstate_reset(fpstate);
|
2021-10-22 20:55:51 +02:00
|
|
|
fpstate_init_user(fpstate);
|
|
|
|
|
2022-01-05 04:35:13 -08:00
|
|
|
gfpu->fpstate = fpstate;
|
2025-05-22 08:10:06 -07:00
|
|
|
gfpu->xfeatures = guest_default_cfg.features;
|
2022-05-04 00:12:19 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* KVM sets the FP+SSE bits in the XSAVE header when copying FPU state
|
|
|
|
* to userspace, even when XSAVE is unsupported, so that restoring FPU
|
|
|
|
* state on a different CPU that does support XSAVE can cleanly load
|
|
|
|
* the incoming state using its natural XSAVE. In other words, KVM's
|
|
|
|
* uABI size may be larger than this host's default size. Conversely,
|
|
|
|
* the default size should never be larger than KVM's base uABI size;
|
|
|
|
* all features that can expand the uABI size must be opt-in.
|
|
|
|
*/
|
|
|
|
gfpu->uabi_size = sizeof(struct kvm_xsave);
|
|
|
|
if (WARN_ON_ONCE(fpu_user_cfg.default_size > gfpu->uabi_size))
|
|
|
|
gfpu->uabi_size = fpu_user_cfg.default_size;
|
|
|
|
|
2025-05-06 17:36:07 +08:00
|
|
|
fpu_lock_guest_permissions();
|
2022-01-05 04:35:13 -08:00
|
|
|
|
2021-10-22 20:55:51 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpu_alloc_guest_fpstate);
|
|
|
|
|
|
|
|
void fpu_free_guest_fpstate(struct fpu_guest *gfpu)
|
|
|
|
{
|
2025-04-09 23:11:27 +02:00
|
|
|
struct fpstate *fpstate = gfpu->fpstate;
|
2021-10-22 20:55:51 +02:00
|
|
|
|
2025-04-09 23:11:27 +02:00
|
|
|
if (!fpstate)
|
2021-10-22 20:55:51 +02:00
|
|
|
return;
|
|
|
|
|
2025-04-09 23:11:27 +02:00
|
|
|
if (WARN_ON_ONCE(!fpstate->is_valloc || !fpstate->is_guest || fpstate->in_use))
|
2021-10-22 20:55:51 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
gfpu->fpstate = NULL;
|
2025-04-09 23:11:27 +02:00
|
|
|
vfree(fpstate);
|
2021-10-22 20:55:51 +02:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpu_free_guest_fpstate);
|
|
|
|
|
2022-01-05 04:35:18 -08:00
|
|
|
/*
|
|
|
|
* fpu_enable_guest_xfd_features - Check xfeatures against guest perm and enable
|
|
|
|
* @guest_fpu: Pointer to the guest FPU container
|
|
|
|
* @xfeatures: Features requested by guest CPUID
|
|
|
|
*
|
|
|
|
* Enable all dynamic xfeatures according to guest perm and requested CPUID.
|
|
|
|
*
|
|
|
|
* Return: 0 on success, error code otherwise
|
|
|
|
*/
|
|
|
|
int fpu_enable_guest_xfd_features(struct fpu_guest *guest_fpu, u64 xfeatures)
|
|
|
|
{
|
|
|
|
lockdep_assert_preemption_enabled();
|
|
|
|
|
|
|
|
/* Nothing to do if all requested features are already enabled. */
|
|
|
|
xfeatures &= ~guest_fpu->xfeatures;
|
|
|
|
if (!xfeatures)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return __xfd_enable_feature(xfeatures, guest_fpu);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpu_enable_guest_xfd_features);
|
|
|
|
|
2022-01-05 04:35:20 -08:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
void fpu_update_guest_xfd(struct fpu_guest *guest_fpu, u64 xfd)
|
|
|
|
{
|
|
|
|
fpregs_lock();
|
|
|
|
guest_fpu->fpstate->xfd = xfd;
|
|
|
|
if (guest_fpu->fpstate->in_use)
|
|
|
|
xfd_update_state(guest_fpu->fpstate);
|
|
|
|
fpregs_unlock();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpu_update_guest_xfd);
|
2022-01-05 04:35:31 -08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* fpu_sync_guest_vmexit_xfd_state - Synchronize XFD MSR and software state
|
|
|
|
*
|
|
|
|
* Must be invoked from KVM after a VMEXIT before enabling interrupts when
|
|
|
|
* XFD write emulation is disabled. This is required because the guest can
|
|
|
|
* freely modify XFD and the state at VMEXIT is not guaranteed to be the
|
2024-01-02 18:40:11 -06:00
|
|
|
* same as the state on VMENTER. So software state has to be updated before
|
2022-01-05 04:35:31 -08:00
|
|
|
* any operation which depends on it can take place.
|
|
|
|
*
|
|
|
|
* Note: It can be invoked unconditionally even when write emulation is
|
|
|
|
* enabled for the price of a then pointless MSR read.
|
|
|
|
*/
|
|
|
|
void fpu_sync_guest_vmexit_xfd_state(void)
|
|
|
|
{
|
2025-04-09 23:11:27 +02:00
|
|
|
struct fpstate *fpstate = x86_task_fpu(current)->fpstate;
|
2022-01-05 04:35:31 -08:00
|
|
|
|
|
|
|
lockdep_assert_irqs_disabled();
|
|
|
|
if (fpu_state_size_dynamic()) {
|
2025-05-13 10:42:06 +02:00
|
|
|
rdmsrq(MSR_IA32_XFD, fpstate->xfd);
|
2025-04-09 23:11:27 +02:00
|
|
|
__this_cpu_write(xfd_state, fpstate->xfd);
|
2022-01-05 04:35:31 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpu_sync_guest_vmexit_xfd_state);
|
2022-01-05 04:35:20 -08:00
|
|
|
#endif /* CONFIG_X86_64 */
|
|
|
|
|
2021-10-22 20:55:51 +02:00
|
|
|
int fpu_swap_kvm_fpstate(struct fpu_guest *guest_fpu, bool enter_guest)
|
|
|
|
{
|
|
|
|
struct fpstate *guest_fps = guest_fpu->fpstate;
|
2025-04-09 23:11:21 +02:00
|
|
|
struct fpu *fpu = x86_task_fpu(current);
|
2021-10-22 20:55:51 +02:00
|
|
|
struct fpstate *cur_fps = fpu->fpstate;
|
|
|
|
|
|
|
|
fpregs_lock();
|
|
|
|
if (!cur_fps->is_confidential && !test_thread_flag(TIF_NEED_FPU_LOAD))
|
|
|
|
save_fpregs_to_fpstate(fpu);
|
|
|
|
|
|
|
|
/* Swap fpstate */
|
|
|
|
if (enter_guest) {
|
|
|
|
fpu->__task_fpstate = cur_fps;
|
|
|
|
fpu->fpstate = guest_fps;
|
|
|
|
guest_fps->in_use = true;
|
|
|
|
} else {
|
|
|
|
guest_fps->in_use = false;
|
|
|
|
fpu->fpstate = fpu->__task_fpstate;
|
|
|
|
fpu->__task_fpstate = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
cur_fps = fpu->fpstate;
|
|
|
|
|
2021-10-21 15:55:20 -07:00
|
|
|
if (!cur_fps->is_confidential) {
|
|
|
|
/* Includes XFD update */
|
2021-10-22 20:55:51 +02:00
|
|
|
restore_fpregs_from_fpstate(cur_fps, XFEATURE_MASK_FPSTATE);
|
2021-10-21 15:55:20 -07:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* XSTATE is restored by firmware from encrypted
|
|
|
|
* memory. Make sure XFD state is correct while
|
|
|
|
* running with guest fpstate
|
|
|
|
*/
|
|
|
|
xfd_update_state(cur_fps);
|
|
|
|
}
|
2021-10-22 20:55:51 +02:00
|
|
|
|
|
|
|
fpregs_mark_activate();
|
|
|
|
fpregs_unlock();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpu_swap_kvm_fpstate);
|
|
|
|
|
2021-10-22 20:55:53 +02:00
|
|
|
void fpu_copy_guest_fpstate_to_uabi(struct fpu_guest *gfpu, void *buf,
|
2023-09-27 17:19:52 -07:00
|
|
|
unsigned int size, u64 xfeatures, u32 pkru)
|
2021-10-15 03:16:17 +02:00
|
|
|
{
|
2021-10-22 20:55:53 +02:00
|
|
|
struct fpstate *kstate = gfpu->fpstate;
|
2021-10-15 03:16:17 +02:00
|
|
|
union fpregs_state *ustate = buf;
|
|
|
|
struct membuf mb = { .p = buf, .left = size };
|
|
|
|
|
|
|
|
if (cpu_feature_enabled(X86_FEATURE_XSAVE)) {
|
2023-09-27 17:19:52 -07:00
|
|
|
__copy_xstate_to_uabi_buf(mb, kstate, xfeatures, pkru,
|
|
|
|
XSTATE_COPY_XSAVE);
|
2021-10-15 03:16:17 +02:00
|
|
|
} else {
|
2021-10-13 16:55:54 +02:00
|
|
|
memcpy(&ustate->fxsave, &kstate->regs.fxsave,
|
|
|
|
sizeof(ustate->fxsave));
|
2021-10-15 03:16:17 +02:00
|
|
|
/* Make it restorable on a XSAVE enabled host */
|
|
|
|
ustate->xsave.header.xfeatures = XFEATURE_MASK_FPSSE;
|
|
|
|
}
|
|
|
|
}
|
2021-10-22 20:55:53 +02:00
|
|
|
EXPORT_SYMBOL_GPL(fpu_copy_guest_fpstate_to_uabi);
|
2021-10-15 03:16:17 +02:00
|
|
|
|
2021-10-22 20:55:53 +02:00
|
|
|
int fpu_copy_uabi_to_guest_fpstate(struct fpu_guest *gfpu, const void *buf,
|
|
|
|
u64 xcr0, u32 *vpkru)
|
2021-10-15 03:16:13 +02:00
|
|
|
{
|
2021-10-22 20:55:53 +02:00
|
|
|
struct fpstate *kstate = gfpu->fpstate;
|
2021-10-15 03:16:13 +02:00
|
|
|
const union fpregs_state *ustate = buf;
|
|
|
|
|
|
|
|
if (!cpu_feature_enabled(X86_FEATURE_XSAVE)) {
|
|
|
|
if (ustate->xsave.header.xfeatures & ~XFEATURE_MASK_FPSSE)
|
|
|
|
return -EINVAL;
|
|
|
|
if (ustate->fxsave.mxcsr & ~mxcsr_feature_mask)
|
|
|
|
return -EINVAL;
|
2021-10-13 16:55:52 +02:00
|
|
|
memcpy(&kstate->regs.fxsave, &ustate->fxsave, sizeof(ustate->fxsave));
|
2021-10-15 03:16:13 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ustate->xsave.header.xfeatures & ~xcr0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2022-11-15 15:09:31 -08:00
|
|
|
/*
|
|
|
|
* Nullify @vpkru to preserve its current value if PKRU's bit isn't set
|
|
|
|
* in the header. KVM's odd ABI is to leave PKRU untouched in this
|
|
|
|
* case (all other components are eventually re-initialized).
|
|
|
|
*/
|
|
|
|
if (!(ustate->xsave.header.xfeatures & XFEATURE_MASK_PKRU))
|
|
|
|
vpkru = NULL;
|
2021-10-15 03:16:13 +02:00
|
|
|
|
2022-11-15 15:09:30 -08:00
|
|
|
return copy_uabi_from_kernel_to_xstate(kstate, ustate, vpkru);
|
2021-10-15 03:16:13 +02:00
|
|
|
}
|
2021-10-22 20:55:53 +02:00
|
|
|
EXPORT_SYMBOL_GPL(fpu_copy_uabi_to_guest_fpstate);
|
2021-10-15 03:16:13 +02:00
|
|
|
#endif /* CONFIG_KVM */
|
2021-06-23 14:02:15 +02:00
|
|
|
|
2021-01-20 21:09:48 -08:00
|
|
|
void kernel_fpu_begin_mask(unsigned int kfpu_mask)
|
2012-02-21 10:25:45 -08:00
|
|
|
{
|
x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs
Background:
===========
Currently kernel-mode FPU is not always usable in softirq context on
x86, since softirqs can nest inside a kernel-mode FPU section in task
context, and nested use of kernel-mode FPU is not supported.
Therefore, x86 SIMD-optimized code that can be called in softirq context
has to sometimes fall back to non-SIMD code. There are two options for
the fallback, both of which are pretty terrible:
(a) Use a scalar fallback. This can be 10-100x slower than vectorized
code because it cannot use specialized instructions like AES, SHA,
or carryless multiplication.
(b) Execute the request asynchronously using a kworker. In other
words, use the "crypto SIMD helper" in crypto/simd.c.
Currently most of the x86 en/decryption code (skcipher and aead
algorithms) uses option (b), since this avoids the slow scalar fallback
and it is easier to wire up. But option (b) is still really bad for its
own reasons:
- Punting the request to a kworker is bad for performance too.
- It forces the algorithm to be marked as asynchronous
(CRYPTO_ALG_ASYNC), preventing it from being used by crypto API
users who request a synchronous algorithm. That's another huge
performance problem, which is especially unfortunate for users who
don't even do en/decryption in softirq context.
- It makes all en/decryption operations take a detour through
crypto/simd.c. That involves additional checks and an additional
indirect call, which slow down en/decryption for *everyone*.
Fortunately, the skcipher and aead APIs are only usable in task and
softirq context in the first place. Thus, if kernel-mode FPU were to be
reliably usable in softirq context, no fallback would be needed.
Indeed, other architectures such as arm, arm64, and riscv have already
done this.
Changes implemented:
====================
Therefore, this patch updates x86 accordingly to reliably support
kernel-mode FPU in softirqs.
This is done by just disabling softirq processing in kernel-mode FPU
sections (when hardirqs are not already disabled), as that prevents the
nesting that was problematic.
This will delay some softirqs slightly, but only ones that would have
otherwise been nested inside a task context kernel-mode FPU section.
Any such softirqs would have taken the slow fallback path before if they
tried to do any en/decryption. Now these softirqs will just run at the
end of the task context kernel-mode FPU section (since local_bh_enable()
runs pending softirqs) and will no longer take the slow fallback path.
Alternatives considered:
========================
- Make kernel-mode FPU sections fully preemptible. This would require
growing task_struct by another struct fpstate which is more than 2K.
- Make softirqs save/restore the kernel-mode FPU state to a per-CPU
struct fpstate when nested use is detected. Somewhat interesting, but
seems unnecessary when a simpler solution exists.
Performance results:
====================
I did some benchmarks with AES-XTS encryption of 16-byte messages (which is
unrealistically small, but this makes it easier to see the overhead of
kernel-mode FPU...). The baseline was 384 MB/s. Removing the use of
crypto/simd.c, which this work makes possible, increases it to 487 MB/s,
a +27% improvement in throughput.
CPU was AMD Ryzen 9 9950X (Zen 5). No debugging options were enabled.
[ mingo: Prettified the changelog and added performance results. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>
Link: https://lore.kernel.org/r/20250304204954.3901-1-ebiggers@kernel.org
2025-03-04 12:49:54 -08:00
|
|
|
if (!irqs_disabled())
|
|
|
|
fpregs_lock();
|
2012-02-21 10:25:45 -08:00
|
|
|
|
2015-05-05 11:34:49 +02:00
|
|
|
WARN_ON_FPU(!irq_fpu_usable());
|
2015-05-01 10:54:22 +02:00
|
|
|
|
2025-05-18 12:32:12 -07:00
|
|
|
/* Toggle kernel_fpu_allowed to false: */
|
|
|
|
WARN_ON_FPU(!this_cpu_read(kernel_fpu_allowed));
|
|
|
|
this_cpu_write(kernel_fpu_allowed, false);
|
2019-06-04 09:15:23 +02:00
|
|
|
|
2023-06-01 13:32:32 -05:00
|
|
|
if (!(current->flags & (PF_KTHREAD | PF_USER_WORKER)) &&
|
2019-06-04 09:15:23 +02:00
|
|
|
!test_thread_flag(TIF_NEED_FPU_LOAD)) {
|
|
|
|
set_thread_flag(TIF_NEED_FPU_LOAD);
|
2025-04-09 23:11:21 +02:00
|
|
|
save_fpregs_to_fpstate(x86_task_fpu(current));
|
2012-02-21 10:25:45 -08:00
|
|
|
}
|
2019-04-03 18:41:52 +02:00
|
|
|
__cpu_invalidate_fpregs_state();
|
2020-06-16 11:12:57 +02:00
|
|
|
|
2021-01-20 21:09:48 -08:00
|
|
|
/* Put sane initial values into the control registers. */
|
|
|
|
if (likely(kfpu_mask & KFPU_MXCSR) && boot_cpu_has(X86_FEATURE_XMM))
|
2020-06-16 11:12:57 +02:00
|
|
|
ldmxcsr(MXCSR_DEFAULT);
|
|
|
|
|
2021-01-20 21:09:48 -08:00
|
|
|
if (unlikely(kfpu_mask & KFPU_387) && boot_cpu_has(X86_FEATURE_FPU))
|
2020-06-16 11:12:57 +02:00
|
|
|
asm volatile ("fninit");
|
2012-02-21 10:25:45 -08:00
|
|
|
}
|
2021-01-20 21:09:48 -08:00
|
|
|
EXPORT_SYMBOL_GPL(kernel_fpu_begin_mask);
|
2015-04-26 12:07:18 +02:00
|
|
|
|
|
|
|
void kernel_fpu_end(void)
|
|
|
|
{
|
2025-05-18 12:32:12 -07:00
|
|
|
/* Toggle kernel_fpu_allowed back to true: */
|
|
|
|
WARN_ON_FPU(this_cpu_read(kernel_fpu_allowed));
|
|
|
|
this_cpu_write(kernel_fpu_allowed, true);
|
2019-06-04 09:15:22 +02:00
|
|
|
|
x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs
Background:
===========
Currently kernel-mode FPU is not always usable in softirq context on
x86, since softirqs can nest inside a kernel-mode FPU section in task
context, and nested use of kernel-mode FPU is not supported.
Therefore, x86 SIMD-optimized code that can be called in softirq context
has to sometimes fall back to non-SIMD code. There are two options for
the fallback, both of which are pretty terrible:
(a) Use a scalar fallback. This can be 10-100x slower than vectorized
code because it cannot use specialized instructions like AES, SHA,
or carryless multiplication.
(b) Execute the request asynchronously using a kworker. In other
words, use the "crypto SIMD helper" in crypto/simd.c.
Currently most of the x86 en/decryption code (skcipher and aead
algorithms) uses option (b), since this avoids the slow scalar fallback
and it is easier to wire up. But option (b) is still really bad for its
own reasons:
- Punting the request to a kworker is bad for performance too.
- It forces the algorithm to be marked as asynchronous
(CRYPTO_ALG_ASYNC), preventing it from being used by crypto API
users who request a synchronous algorithm. That's another huge
performance problem, which is especially unfortunate for users who
don't even do en/decryption in softirq context.
- It makes all en/decryption operations take a detour through
crypto/simd.c. That involves additional checks and an additional
indirect call, which slow down en/decryption for *everyone*.
Fortunately, the skcipher and aead APIs are only usable in task and
softirq context in the first place. Thus, if kernel-mode FPU were to be
reliably usable in softirq context, no fallback would be needed.
Indeed, other architectures such as arm, arm64, and riscv have already
done this.
Changes implemented:
====================
Therefore, this patch updates x86 accordingly to reliably support
kernel-mode FPU in softirqs.
This is done by just disabling softirq processing in kernel-mode FPU
sections (when hardirqs are not already disabled), as that prevents the
nesting that was problematic.
This will delay some softirqs slightly, but only ones that would have
otherwise been nested inside a task context kernel-mode FPU section.
Any such softirqs would have taken the slow fallback path before if they
tried to do any en/decryption. Now these softirqs will just run at the
end of the task context kernel-mode FPU section (since local_bh_enable()
runs pending softirqs) and will no longer take the slow fallback path.
Alternatives considered:
========================
- Make kernel-mode FPU sections fully preemptible. This would require
growing task_struct by another struct fpstate which is more than 2K.
- Make softirqs save/restore the kernel-mode FPU state to a per-CPU
struct fpstate when nested use is detected. Somewhat interesting, but
seems unnecessary when a simpler solution exists.
Performance results:
====================
I did some benchmarks with AES-XTS encryption of 16-byte messages (which is
unrealistically small, but this makes it easier to see the overhead of
kernel-mode FPU...). The baseline was 384 MB/s. Removing the use of
crypto/simd.c, which this work makes possible, increases it to 487 MB/s,
a +27% improvement in throughput.
CPU was AMD Ryzen 9 9950X (Zen 5). No debugging options were enabled.
[ mingo: Prettified the changelog and added performance results. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Uros Bizjak <ubizjak@gmail.com>
Link: https://lore.kernel.org/r/20250304204954.3901-1-ebiggers@kernel.org
2025-03-04 12:49:54 -08:00
|
|
|
if (!irqs_disabled())
|
|
|
|
fpregs_unlock();
|
2015-04-26 12:07:18 +02:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kernel_fpu_end);
|
|
|
|
|
2015-04-03 11:01:36 +02:00
|
|
|
/*
|
2021-06-23 14:02:06 +02:00
|
|
|
* Sync the FPU register state to current's memory register state when the
|
|
|
|
* current task owns the FPU. The hardware register state is preserved.
|
2015-04-03 11:01:36 +02:00
|
|
|
*/
|
2021-06-23 14:02:06 +02:00
|
|
|
void fpu_sync_fpstate(struct fpu *fpu)
|
2012-02-21 10:25:45 -08:00
|
|
|
{
|
2025-04-09 23:11:21 +02:00
|
|
|
WARN_ON_FPU(fpu != x86_task_fpu(current));
|
2015-04-03 11:06:43 +02:00
|
|
|
|
2019-04-03 18:41:52 +02:00
|
|
|
fpregs_lock();
|
2016-06-01 10:42:20 -07:00
|
|
|
trace_x86_fpu_before_save(fpu);
|
2019-04-03 18:41:36 +02:00
|
|
|
|
2021-06-23 14:02:00 +02:00
|
|
|
if (!test_thread_flag(TIF_NEED_FPU_LOAD))
|
|
|
|
save_fpregs_to_fpstate(fpu);
|
2019-04-03 18:41:36 +02:00
|
|
|
|
2016-06-01 10:42:20 -07:00
|
|
|
trace_x86_fpu_after_save(fpu);
|
2019-04-03 18:41:52 +02:00
|
|
|
fpregs_unlock();
|
2012-02-21 10:25:45 -08:00
|
|
|
}
|
|
|
|
|
2021-10-15 03:16:06 +02:00
|
|
|
static inline unsigned int init_fpstate_copy_size(void)
|
|
|
|
{
|
|
|
|
if (!use_xsave())
|
2021-10-15 01:09:34 +02:00
|
|
|
return fpu_kernel_cfg.default_size;
|
2021-10-15 03:16:06 +02:00
|
|
|
|
|
|
|
/* XSAVE(S) just needs the legacy and the xstate header part */
|
2021-10-13 16:55:28 +02:00
|
|
|
return sizeof(init_fpstate.regs.xsave);
|
2021-10-15 03:16:06 +02:00
|
|
|
}
|
|
|
|
|
2021-10-13 16:55:28 +02:00
|
|
|
static inline void fpstate_init_fxstate(struct fpstate *fpstate)
|
2021-06-23 14:01:34 +02:00
|
|
|
{
|
2021-10-13 16:55:28 +02:00
|
|
|
fpstate->regs.fxsave.cwd = 0x37f;
|
|
|
|
fpstate->regs.fxsave.mxcsr = MXCSR_DEFAULT;
|
2021-06-23 14:01:34 +02:00
|
|
|
}
|
|
|
|
|
2015-04-30 10:08:36 +02:00
|
|
|
/*
|
|
|
|
* Legacy x87 fpstate state init:
|
|
|
|
*/
|
2021-10-13 16:55:28 +02:00
|
|
|
static inline void fpstate_init_fstate(struct fpstate *fpstate)
|
2015-04-30 10:08:36 +02:00
|
|
|
{
|
2021-10-13 16:55:28 +02:00
|
|
|
fpstate->regs.fsave.cwd = 0xffff037fu;
|
|
|
|
fpstate->regs.fsave.swd = 0xffff0000u;
|
|
|
|
fpstate->regs.fsave.twd = 0xffffffffu;
|
|
|
|
fpstate->regs.fsave.fos = 0xffff0000u;
|
2015-04-30 10:08:36 +02:00
|
|
|
}
|
|
|
|
|
2021-10-15 03:16:07 +02:00
|
|
|
/*
|
|
|
|
* Used in two places:
|
|
|
|
* 1) Early boot to setup init_fpstate for non XSAVE systems
|
2025-03-24 21:19:27 +08:00
|
|
|
* 2) fpu_alloc_guest_fpstate() which is invoked from KVM
|
2021-10-15 03:16:07 +02:00
|
|
|
*/
|
2021-10-13 16:55:28 +02:00
|
|
|
void fpstate_init_user(struct fpstate *fpstate)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2021-10-15 03:16:07 +02:00
|
|
|
if (!cpu_feature_enabled(X86_FEATURE_FPU)) {
|
2021-10-13 16:55:28 +02:00
|
|
|
fpstate_init_soft(&fpstate->regs.soft);
|
2010-05-06 11:45:46 +03:00
|
|
|
return;
|
2008-05-23 16:26:37 -07:00
|
|
|
}
|
|
|
|
|
2021-10-15 01:09:37 +02:00
|
|
|
xstate_init_xcomp_bv(&fpstate->regs.xsave, fpstate->xfeatures);
|
2015-03-10 07:06:25 +01:00
|
|
|
|
2021-10-15 03:16:07 +02:00
|
|
|
if (cpu_feature_enabled(X86_FEATURE_FXSR))
|
2021-10-13 16:55:28 +02:00
|
|
|
fpstate_init_fxstate(fpstate);
|
2015-04-30 10:08:36 +02:00
|
|
|
else
|
2021-10-13 16:55:28 +02:00
|
|
|
fpstate_init_fstate(fpstate);
|
2010-05-06 11:45:46 +03:00
|
|
|
}
|
2021-10-15 03:16:07 +02:00
|
|
|
|
2025-05-22 08:10:07 -07:00
|
|
|
static void __fpstate_reset(struct fpstate *fpstate)
|
2021-10-22 20:55:51 +02:00
|
|
|
{
|
2025-05-22 08:10:06 -07:00
|
|
|
/*
|
|
|
|
* Supervisor features (and thus sizes) may diverge between guest
|
|
|
|
* FPUs and host FPUs, as some supervisor features are supported
|
|
|
|
* for guests despite not being utilized by the host. User
|
|
|
|
* features and sizes are always identical, which allows for
|
|
|
|
* common guest and userspace ABI.
|
2025-05-22 08:10:07 -07:00
|
|
|
*
|
|
|
|
* For the host, set XFD to the kernel's desired initialization
|
|
|
|
* value. For guests, set XFD to its architectural RESET value.
|
2025-05-22 08:10:06 -07:00
|
|
|
*/
|
|
|
|
if (fpstate->is_guest) {
|
|
|
|
fpstate->size = guest_default_cfg.size;
|
|
|
|
fpstate->xfeatures = guest_default_cfg.features;
|
2025-05-22 08:10:07 -07:00
|
|
|
fpstate->xfd = 0;
|
2025-05-22 08:10:06 -07:00
|
|
|
} else {
|
|
|
|
fpstate->size = fpu_kernel_cfg.default_size;
|
|
|
|
fpstate->xfeatures = fpu_kernel_cfg.default_features;
|
2025-05-22 08:10:07 -07:00
|
|
|
fpstate->xfd = init_fpstate.xfd;
|
2025-05-22 08:10:06 -07:00
|
|
|
}
|
|
|
|
|
2021-10-22 20:55:51 +02:00
|
|
|
fpstate->user_size = fpu_user_cfg.default_size;
|
|
|
|
fpstate->user_xfeatures = fpu_user_cfg.default_features;
|
|
|
|
}
|
|
|
|
|
2021-10-13 16:55:27 +02:00
|
|
|
void fpstate_reset(struct fpu *fpu)
|
|
|
|
{
|
|
|
|
/* Set the fpstate pointer to the default fpstate */
|
|
|
|
fpu->fpstate = &fpu->__fpstate;
|
2025-05-22 08:10:07 -07:00
|
|
|
__fpstate_reset(fpu->fpstate);
|
2021-10-21 15:55:08 -07:00
|
|
|
|
|
|
|
/* Initialize the permission related info in fpu */
|
|
|
|
fpu->perm.__state_perm = fpu_kernel_cfg.default_features;
|
|
|
|
fpu->perm.__state_size = fpu_kernel_cfg.default_size;
|
|
|
|
fpu->perm.__user_state_size = fpu_user_cfg.default_size;
|
2025-05-22 08:10:05 -07:00
|
|
|
|
|
|
|
fpu->guest_perm.__state_perm = guest_default_cfg.features;
|
|
|
|
fpu->guest_perm.__state_size = guest_default_cfg.size;
|
|
|
|
/*
|
|
|
|
* User features and sizes are always identical between host and
|
|
|
|
* guest FPUs, which allows for common guest and userspace ABI.
|
|
|
|
*/
|
|
|
|
fpu->guest_perm.__user_state_size = fpu_user_cfg.default_size;
|
2021-10-13 16:55:27 +02:00
|
|
|
}
|
|
|
|
|
2021-10-21 15:55:14 -07:00
|
|
|
static inline void fpu_inherit_perms(struct fpu *dst_fpu)
|
|
|
|
{
|
|
|
|
if (fpu_state_size_dynamic()) {
|
2025-04-09 23:11:21 +02:00
|
|
|
struct fpu *src_fpu = x86_task_fpu(current->group_leader);
|
2021-10-21 15:55:14 -07:00
|
|
|
|
|
|
|
spin_lock_irq(¤t->sighand->siglock);
|
|
|
|
/* Fork also inherits the permissions of the parent */
|
|
|
|
dst_fpu->perm = src_fpu->perm;
|
2022-01-05 04:35:12 -08:00
|
|
|
dst_fpu->guest_perm = src_fpu->guest_perm;
|
2021-10-21 15:55:14 -07:00
|
|
|
spin_unlock_irq(¤t->sighand->siglock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
x86/shstk: Handle thread shadow stack
When a process is duplicated, but the child shares the address space with
the parent, there is potential for the threads sharing a single stack to
cause conflicts for each other. In the normal non-CET case this is handled
in two ways.
With regular CLONE_VM a new stack is provided by userspace such that the
parent and child have different stacks.
For vfork, the parent is suspended until the child exits. So as long as
the child doesn't return from the vfork()/CLONE_VFORK calling function and
sticks to a limited set of operations, the parent and child can share the
same stack.
For shadow stack, these scenarios present similar sharing problems. For the
CLONE_VM case, the child and the parent must have separate shadow stacks.
Instead of changing clone to take a shadow stack, have the kernel just
allocate one and switch to it.
Use stack_size passed from clone3() syscall for thread shadow stack size. A
compat-mode thread shadow stack size is further reduced to 1/4. This
allows more threads to run in a 32-bit address space. The clone() does not
pass stack_size, which was added to clone3(). In that case, use
RLIMIT_STACK size and cap to 4 GB.
For shadow stack enabled vfork(), the parent and child can share the same
shadow stack, like they can share a normal stack. Since the parent is
suspended until the child terminates, the child will not interfere with
the parent while executing as long as it doesn't return from the vfork()
and overwrite up the shadow stack. The child can safely overwrite down
the shadow stack, as the parent can just overwrite this later. So CET does
not add any additional limitations for vfork().
Free the shadow stack on thread exit by doing it in mm_release(). Skip
this when exiting a vfork() child since the stack is shared in the
parent.
During this operation, the shadow stack pointer of the new thread needs
to be updated to point to the newly allocated shadow stack. Since the
ability to do this is confined to the FPU subsystem, change
fpu_clone() to take the new shadow stack pointer, and update it
internally inside the FPU subsystem. This part was suggested by Thomas
Gleixner.
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Tested-by: John Allen <john.allen@amd.com>
Tested-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/all/20230613001108.3040476-30-rick.p.edgecombe%40intel.com
2023-06-12 17:10:55 -07:00
|
|
|
/* A passed ssp of zero will not cause any update */
|
|
|
|
static int update_fpu_shstk(struct task_struct *dst, unsigned long ssp)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_USER_SHADOW_STACK
|
|
|
|
struct cet_user_state *xstate;
|
|
|
|
|
|
|
|
/* If ssp update is not needed. */
|
|
|
|
if (!ssp)
|
|
|
|
return 0;
|
|
|
|
|
2025-04-09 23:11:21 +02:00
|
|
|
xstate = get_xsave_addr(&x86_task_fpu(dst)->fpstate->regs.xsave,
|
x86/shstk: Handle thread shadow stack
When a process is duplicated, but the child shares the address space with
the parent, there is potential for the threads sharing a single stack to
cause conflicts for each other. In the normal non-CET case this is handled
in two ways.
With regular CLONE_VM a new stack is provided by userspace such that the
parent and child have different stacks.
For vfork, the parent is suspended until the child exits. So as long as
the child doesn't return from the vfork()/CLONE_VFORK calling function and
sticks to a limited set of operations, the parent and child can share the
same stack.
For shadow stack, these scenarios present similar sharing problems. For the
CLONE_VM case, the child and the parent must have separate shadow stacks.
Instead of changing clone to take a shadow stack, have the kernel just
allocate one and switch to it.
Use stack_size passed from clone3() syscall for thread shadow stack size. A
compat-mode thread shadow stack size is further reduced to 1/4. This
allows more threads to run in a 32-bit address space. The clone() does not
pass stack_size, which was added to clone3(). In that case, use
RLIMIT_STACK size and cap to 4 GB.
For shadow stack enabled vfork(), the parent and child can share the same
shadow stack, like they can share a normal stack. Since the parent is
suspended until the child terminates, the child will not interfere with
the parent while executing as long as it doesn't return from the vfork()
and overwrite up the shadow stack. The child can safely overwrite down
the shadow stack, as the parent can just overwrite this later. So CET does
not add any additional limitations for vfork().
Free the shadow stack on thread exit by doing it in mm_release(). Skip
this when exiting a vfork() child since the stack is shared in the
parent.
During this operation, the shadow stack pointer of the new thread needs
to be updated to point to the newly allocated shadow stack. Since the
ability to do this is confined to the FPU subsystem, change
fpu_clone() to take the new shadow stack pointer, and update it
internally inside the FPU subsystem. This part was suggested by Thomas
Gleixner.
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Tested-by: John Allen <john.allen@amd.com>
Tested-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/all/20230613001108.3040476-30-rick.p.edgecombe%40intel.com
2023-06-12 17:10:55 -07:00
|
|
|
XFEATURE_CET_USER);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is a non-zero ssp, then 'dst' must be configured with a shadow
|
|
|
|
* stack and the fpu state should be up to date since it was just copied
|
|
|
|
* from the parent in fpu_clone(). So there must be a valid non-init CET
|
|
|
|
* state location in the buffer.
|
|
|
|
*/
|
|
|
|
if (WARN_ON_ONCE(!xstate))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
xstate->user_ssp = (u64)ssp;
|
|
|
|
#endif
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-06-23 14:02:06 +02:00
|
|
|
/* Clone current's FPU state on fork */
|
x86/shstk: Handle thread shadow stack
When a process is duplicated, but the child shares the address space with
the parent, there is potential for the threads sharing a single stack to
cause conflicts for each other. In the normal non-CET case this is handled
in two ways.
With regular CLONE_VM a new stack is provided by userspace such that the
parent and child have different stacks.
For vfork, the parent is suspended until the child exits. So as long as
the child doesn't return from the vfork()/CLONE_VFORK calling function and
sticks to a limited set of operations, the parent and child can share the
same stack.
For shadow stack, these scenarios present similar sharing problems. For the
CLONE_VM case, the child and the parent must have separate shadow stacks.
Instead of changing clone to take a shadow stack, have the kernel just
allocate one and switch to it.
Use stack_size passed from clone3() syscall for thread shadow stack size. A
compat-mode thread shadow stack size is further reduced to 1/4. This
allows more threads to run in a 32-bit address space. The clone() does not
pass stack_size, which was added to clone3(). In that case, use
RLIMIT_STACK size and cap to 4 GB.
For shadow stack enabled vfork(), the parent and child can share the same
shadow stack, like they can share a normal stack. Since the parent is
suspended until the child terminates, the child will not interfere with
the parent while executing as long as it doesn't return from the vfork()
and overwrite up the shadow stack. The child can safely overwrite down
the shadow stack, as the parent can just overwrite this later. So CET does
not add any additional limitations for vfork().
Free the shadow stack on thread exit by doing it in mm_release(). Skip
this when exiting a vfork() child since the stack is shared in the
parent.
During this operation, the shadow stack pointer of the new thread needs
to be updated to point to the newly allocated shadow stack. Since the
ability to do this is confined to the FPU subsystem, change
fpu_clone() to take the new shadow stack pointer, and update it
internally inside the FPU subsystem. This part was suggested by Thomas
Gleixner.
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Tested-by: John Allen <john.allen@amd.com>
Tested-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/all/20230613001108.3040476-30-rick.p.edgecombe%40intel.com
2023-06-12 17:10:55 -07:00
|
|
|
int fpu_clone(struct task_struct *dst, unsigned long clone_flags, bool minimal,
|
|
|
|
unsigned long ssp)
|
2015-04-22 20:09:29 +02:00
|
|
|
{
|
x86/fpu: Make task_struct::thread constant size
Turn thread.fpu into a pointer. Since most FPU code internals work by passing
around the FPU pointer already, the code generation impact is small.
This allows us to remove the old kludge of task_struct being variable size:
struct task_struct {
...
/*
* New fields for task_struct should be added above here, so that
* they are included in the randomized portion of task_struct.
*/
randomized_struct_fields_end
/* CPU-specific state of this task: */
struct thread_struct thread;
/*
* WARNING: on x86, 'thread_struct' contains a variable-sized
* structure. It *MUST* be at the end of 'task_struct'.
*
* Do not put anything below here!
*/
};
... which creates a number of problems, such as requiring thread_struct to be
the last member of the struct - not allowing it to be struct-randomized, etc.
But the primary motivation is to allow the decoupling of task_struct from
hardware details (<asm/processor.h> in particular), and to eventually allow
the per-task infrastructure:
DECLARE_PER_TASK(type, name);
...
per_task(current, name) = val;
... which requires task_struct to be a constant size struct.
The fpu_thread_struct_whitelist() quirk to hardened usercopy can be removed,
now that the FPU structure is not embedded in the task struct anymore, which
reduces text footprint a bit.
Fixed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chang S. Bae <chang.seok.bae@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250409211127.3544993-4-mingo@kernel.org
2025-04-09 23:11:22 +02:00
|
|
|
/*
|
|
|
|
* We allocate the new FPU structure right after the end of the task struct.
|
|
|
|
* task allocation size already took this into account.
|
|
|
|
*
|
2025-04-10 12:52:16 +02:00
|
|
|
* This is safe because task_struct size is a multiple of cacheline size,
|
|
|
|
* thus x86_task_fpu() will always be cacheline aligned as well.
|
x86/fpu: Make task_struct::thread constant size
Turn thread.fpu into a pointer. Since most FPU code internals work by passing
around the FPU pointer already, the code generation impact is small.
This allows us to remove the old kludge of task_struct being variable size:
struct task_struct {
...
/*
* New fields for task_struct should be added above here, so that
* they are included in the randomized portion of task_struct.
*/
randomized_struct_fields_end
/* CPU-specific state of this task: */
struct thread_struct thread;
/*
* WARNING: on x86, 'thread_struct' contains a variable-sized
* structure. It *MUST* be at the end of 'task_struct'.
*
* Do not put anything below here!
*/
};
... which creates a number of problems, such as requiring thread_struct to be
the last member of the struct - not allowing it to be struct-randomized, etc.
But the primary motivation is to allow the decoupling of task_struct from
hardware details (<asm/processor.h> in particular), and to eventually allow
the per-task infrastructure:
DECLARE_PER_TASK(type, name);
...
per_task(current, name) = val;
... which requires task_struct to be a constant size struct.
The fpu_thread_struct_whitelist() quirk to hardened usercopy can be removed,
now that the FPU structure is not embedded in the task struct anymore, which
reduces text footprint a bit.
Fixed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chang S. Bae <chang.seok.bae@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250409211127.3544993-4-mingo@kernel.org
2025-04-09 23:11:22 +02:00
|
|
|
*/
|
2025-04-09 23:11:26 +02:00
|
|
|
struct fpu *dst_fpu = (void *)dst + sizeof(*dst);
|
x86/fpu: Make task_struct::thread constant size
Turn thread.fpu into a pointer. Since most FPU code internals work by passing
around the FPU pointer already, the code generation impact is small.
This allows us to remove the old kludge of task_struct being variable size:
struct task_struct {
...
/*
* New fields for task_struct should be added above here, so that
* they are included in the randomized portion of task_struct.
*/
randomized_struct_fields_end
/* CPU-specific state of this task: */
struct thread_struct thread;
/*
* WARNING: on x86, 'thread_struct' contains a variable-sized
* structure. It *MUST* be at the end of 'task_struct'.
*
* Do not put anything below here!
*/
};
... which creates a number of problems, such as requiring thread_struct to be
the last member of the struct - not allowing it to be struct-randomized, etc.
But the primary motivation is to allow the decoupling of task_struct from
hardware details (<asm/processor.h> in particular), and to eventually allow
the per-task infrastructure:
DECLARE_PER_TASK(type, name);
...
per_task(current, name) = val;
... which requires task_struct to be a constant size struct.
The fpu_thread_struct_whitelist() quirk to hardened usercopy can be removed,
now that the FPU structure is not embedded in the task struct anymore, which
reduces text footprint a bit.
Fixed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chang S. Bae <chang.seok.bae@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250409211127.3544993-4-mingo@kernel.org
2025-04-09 23:11:22 +02:00
|
|
|
|
|
|
|
BUILD_BUG_ON(sizeof(*dst) % SMP_CACHE_BYTES != 0);
|
2019-04-03 18:41:52 +02:00
|
|
|
|
2021-06-23 14:02:06 +02:00
|
|
|
/* The new task's FPU state cannot be valid in the hardware. */
|
2016-01-24 14:38:08 -08:00
|
|
|
dst_fpu->last_cpu = -1;
|
|
|
|
|
2021-10-13 16:55:27 +02:00
|
|
|
fpstate_reset(dst_fpu);
|
|
|
|
|
2021-06-23 14:02:06 +02:00
|
|
|
if (!cpu_feature_enabled(X86_FEATURE_FPU))
|
2016-01-24 14:38:08 -08:00
|
|
|
return 0;
|
|
|
|
|
2021-10-15 03:16:06 +02:00
|
|
|
/*
|
|
|
|
* Enforce reload for user space tasks and prevent kernel threads
|
|
|
|
* from trying to save the FPU registers on context switch.
|
|
|
|
*/
|
|
|
|
set_tsk_thread_flag(dst, TIF_NEED_FPU_LOAD);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No FPU state inheritance for kernel threads and IO
|
|
|
|
* worker threads.
|
|
|
|
*/
|
2022-04-12 10:18:48 -05:00
|
|
|
if (minimal) {
|
2021-10-15 03:16:06 +02:00
|
|
|
/* Clear out the minimal state */
|
2021-10-13 16:55:39 +02:00
|
|
|
memcpy(&dst_fpu->fpstate->regs, &init_fpstate.regs,
|
2021-10-15 03:16:06 +02:00
|
|
|
init_fpstate_copy_size());
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-21 15:55:27 -07:00
|
|
|
/*
|
|
|
|
* If a new feature is added, ensure all dynamic features are
|
|
|
|
* caller-saved from here!
|
|
|
|
*/
|
|
|
|
BUILD_BUG_ON(XFEATURE_MASK_USER_DYNAMIC != XFEATURE_MASK_XTILE_DATA);
|
|
|
|
|
2015-04-27 10:08:39 +02:00
|
|
|
/*
|
2021-10-21 15:55:14 -07:00
|
|
|
* Save the default portion of the current FPU state into the
|
|
|
|
* clone. Assume all dynamic features to be defined as caller-
|
|
|
|
* saved, which enables skipping both the expansion of fpstate
|
|
|
|
* and the copying of any dynamic state.
|
|
|
|
*
|
|
|
|
* Do not use memcpy() when TIF_NEED_FPU_LOAD is set because
|
|
|
|
* copying is not valid when current uses non-default states.
|
2015-04-27 10:08:39 +02:00
|
|
|
*/
|
2019-04-03 18:41:52 +02:00
|
|
|
fpregs_lock();
|
2021-10-21 15:55:14 -07:00
|
|
|
if (test_thread_flag(TIF_NEED_FPU_LOAD))
|
|
|
|
fpregs_restore_userregs();
|
|
|
|
save_fpregs_to_fpstate(dst_fpu);
|
2022-11-10 12:44:00 +00:00
|
|
|
fpregs_unlock();
|
2021-10-21 15:55:14 -07:00
|
|
|
if (!(clone_flags & CLONE_THREAD))
|
|
|
|
fpu_inherit_perms(dst_fpu);
|
2019-04-03 18:41:52 +02:00
|
|
|
|
2022-02-07 15:02:49 -08:00
|
|
|
/*
|
|
|
|
* Children never inherit PASID state.
|
|
|
|
* Force it to have its init value:
|
|
|
|
*/
|
|
|
|
if (use_xsave())
|
|
|
|
dst_fpu->fpstate->regs.xsave.header.xfeatures &= ~XFEATURE_MASK_PASID;
|
|
|
|
|
x86/shstk: Handle thread shadow stack
When a process is duplicated, but the child shares the address space with
the parent, there is potential for the threads sharing a single stack to
cause conflicts for each other. In the normal non-CET case this is handled
in two ways.
With regular CLONE_VM a new stack is provided by userspace such that the
parent and child have different stacks.
For vfork, the parent is suspended until the child exits. So as long as
the child doesn't return from the vfork()/CLONE_VFORK calling function and
sticks to a limited set of operations, the parent and child can share the
same stack.
For shadow stack, these scenarios present similar sharing problems. For the
CLONE_VM case, the child and the parent must have separate shadow stacks.
Instead of changing clone to take a shadow stack, have the kernel just
allocate one and switch to it.
Use stack_size passed from clone3() syscall for thread shadow stack size. A
compat-mode thread shadow stack size is further reduced to 1/4. This
allows more threads to run in a 32-bit address space. The clone() does not
pass stack_size, which was added to clone3(). In that case, use
RLIMIT_STACK size and cap to 4 GB.
For shadow stack enabled vfork(), the parent and child can share the same
shadow stack, like they can share a normal stack. Since the parent is
suspended until the child terminates, the child will not interfere with
the parent while executing as long as it doesn't return from the vfork()
and overwrite up the shadow stack. The child can safely overwrite down
the shadow stack, as the parent can just overwrite this later. So CET does
not add any additional limitations for vfork().
Free the shadow stack on thread exit by doing it in mm_release(). Skip
this when exiting a vfork() child since the stack is shared in the
parent.
During this operation, the shadow stack pointer of the new thread needs
to be updated to point to the newly allocated shadow stack. Since the
ability to do this is confined to the FPU subsystem, change
fpu_clone() to take the new shadow stack pointer, and update it
internally inside the FPU subsystem. This part was suggested by Thomas
Gleixner.
Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Mike Rapoport (IBM) <rppt@kernel.org>
Tested-by: Pengfei Xu <pengfei.xu@intel.com>
Tested-by: John Allen <john.allen@amd.com>
Tested-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/all/20230613001108.3040476-30-rick.p.edgecombe%40intel.com
2023-06-12 17:10:55 -07:00
|
|
|
/*
|
|
|
|
* Update shadow stack pointer, in case it changed during clone.
|
|
|
|
*/
|
|
|
|
if (update_fpu_shstk(dst, ssp))
|
|
|
|
return 1;
|
|
|
|
|
2016-06-01 10:42:20 -07:00
|
|
|
trace_x86_fpu_copy_dst(dst_fpu);
|
|
|
|
|
2015-04-22 15:47:05 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-13 16:55:45 +02:00
|
|
|
/*
|
x86/fpu: Restore fpu_thread_struct_whitelist() to fix CONFIG_HARDENED_USERCOPY=y crash
Borislav Petkov reported the following boot crash on x86-32,
with CONFIG_HARDENED_USERCOPY=y:
| usercopy: Kernel memory overwrite attempt detected to SLUB object 'task_struct' (offset 2112, size 160)!
| ...
| kernel BUG at mm/usercopy.c:102!
So the useroffset and usersize arguments are what control the allowed
window of copying in/out of the "task_struct" kmem cache:
/* create a slab on which task_structs can be allocated */
task_struct_whitelist(&useroffset, &usersize);
task_struct_cachep = kmem_cache_create_usercopy("task_struct",
arch_task_struct_size, align,
SLAB_PANIC|SLAB_ACCOUNT,
useroffset, usersize, NULL);
task_struct_whitelist() positions this window based on the location of
the thread_struct within task_struct, and gets the arch-specific details
via arch_thread_struct_whitelist(offset, size):
static void __init task_struct_whitelist(unsigned long *offset, unsigned long *size)
{
/* Fetch thread_struct whitelist for the architecture. */
arch_thread_struct_whitelist(offset, size);
/*
* Handle zero-sized whitelist or empty thread_struct, otherwise
* adjust offset to position of thread_struct in task_struct.
*/
if (unlikely(*size == 0))
*offset = 0;
else
*offset += offsetof(struct task_struct, thread);
}
Commit cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size")
removed the logic for the window, leaving:
static inline void
arch_thread_struct_whitelist(unsigned long *offset, unsigned long *size)
{
*offset = 0;
*size = 0;
}
So now there is no window that usercopy hardening will allow to be copied
in/out of task_struct.
But as reported above, there *is* a copy in copy_uabi_to_xstate(). (It
seems there are several, actually.)
int copy_sigframe_from_user_to_xstate(struct task_struct *tsk,
const void __user *ubuf)
{
return copy_uabi_to_xstate(x86_task_fpu(tsk)->fpstate, NULL, ubuf, &tsk->thread.pkru);
}
This appears to be writing into x86_task_fpu(tsk)->fpstate. With or
without CONFIG_X86_DEBUG_FPU, this resolves to:
((struct fpu *)((void *)(task) + sizeof(*(task))))
i.e. the memory "after task_struct" is cast to "struct fpu", and the
uses the "fpstate" pointer. How that pointer gets set looks to be
variable, but I think the one we care about here is:
fpu->fpstate = &fpu->__fpstate;
And struct fpu::__fpstate says:
struct fpstate __fpstate;
/*
* WARNING: '__fpstate' is dynamically-sized. Do not put
* anything after it here.
*/
So we're still dealing with a dynamically sized thing, even if it's not
within the literal struct task_struct -- it's still in the kmem cache,
though.
Looking at the kmem cache size, it has allocated "arch_task_struct_size"
bytes, which is calculated in fpu__init_task_struct_size():
int task_size = sizeof(struct task_struct);
task_size += sizeof(struct fpu);
/*
* Subtract off the static size of the register state.
* It potentially has a bunch of padding.
*/
task_size -= sizeof(union fpregs_state);
/*
* Add back the dynamically-calculated register state
* size.
*/
task_size += fpu_kernel_cfg.default_size;
/*
* We dynamically size 'struct fpu', so we require that
* 'state' be at the end of 'it:
*/
CHECK_MEMBER_AT_END_OF(struct fpu, __fpstate);
arch_task_struct_size = task_size;
So, this is still copying out of the kmem cache for task_struct, and the
window seems unchanged (still fpu regs). This is what the window was
before:
void fpu_thread_struct_whitelist(unsigned long *offset, unsigned long *size)
{
*offset = offsetof(struct thread_struct, fpu.__fpstate.regs);
*size = fpu_kernel_cfg.default_size;
}
And the same commit I mentioned above removed it.
I think the misunderstanding is here:
| The fpu_thread_struct_whitelist() quirk to hardened usercopy can be removed,
| now that the FPU structure is not embedded in the task struct anymore, which
| reduces text footprint a bit.
Yes, FPU is no longer in task_struct, but it IS in the kmem cache named
"task_struct", since the fpstate is still being allocated there.
Partially revert the earlier mentioned commit, along with a
recalculation of the fpstate regs location.
Fixes: cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size")
Reported-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Chang S. Bae <chang.seok.bae@intel.com>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-hardening@vger.kernel.org
Link: https://lore.kernel.org/all/20250409211127.3544993-1-mingo@kernel.org/ # Discussion #1
Link: https://lore.kernel.org/r/202505041418.F47130C4C8@keescook # Discussion #2
2025-05-04 15:30:38 -07:00
|
|
|
* While struct fpu is no longer part of struct thread_struct, it is still
|
|
|
|
* allocated after struct task_struct in the "task_struct" kmem cache. But
|
|
|
|
* since FPU is expected to be part of struct thread_struct, we have to
|
|
|
|
* adjust for it here.
|
2021-10-13 16:55:45 +02:00
|
|
|
*/
|
|
|
|
void fpu_thread_struct_whitelist(unsigned long *offset, unsigned long *size)
|
|
|
|
{
|
x86/fpu: Restore fpu_thread_struct_whitelist() to fix CONFIG_HARDENED_USERCOPY=y crash
Borislav Petkov reported the following boot crash on x86-32,
with CONFIG_HARDENED_USERCOPY=y:
| usercopy: Kernel memory overwrite attempt detected to SLUB object 'task_struct' (offset 2112, size 160)!
| ...
| kernel BUG at mm/usercopy.c:102!
So the useroffset and usersize arguments are what control the allowed
window of copying in/out of the "task_struct" kmem cache:
/* create a slab on which task_structs can be allocated */
task_struct_whitelist(&useroffset, &usersize);
task_struct_cachep = kmem_cache_create_usercopy("task_struct",
arch_task_struct_size, align,
SLAB_PANIC|SLAB_ACCOUNT,
useroffset, usersize, NULL);
task_struct_whitelist() positions this window based on the location of
the thread_struct within task_struct, and gets the arch-specific details
via arch_thread_struct_whitelist(offset, size):
static void __init task_struct_whitelist(unsigned long *offset, unsigned long *size)
{
/* Fetch thread_struct whitelist for the architecture. */
arch_thread_struct_whitelist(offset, size);
/*
* Handle zero-sized whitelist or empty thread_struct, otherwise
* adjust offset to position of thread_struct in task_struct.
*/
if (unlikely(*size == 0))
*offset = 0;
else
*offset += offsetof(struct task_struct, thread);
}
Commit cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size")
removed the logic for the window, leaving:
static inline void
arch_thread_struct_whitelist(unsigned long *offset, unsigned long *size)
{
*offset = 0;
*size = 0;
}
So now there is no window that usercopy hardening will allow to be copied
in/out of task_struct.
But as reported above, there *is* a copy in copy_uabi_to_xstate(). (It
seems there are several, actually.)
int copy_sigframe_from_user_to_xstate(struct task_struct *tsk,
const void __user *ubuf)
{
return copy_uabi_to_xstate(x86_task_fpu(tsk)->fpstate, NULL, ubuf, &tsk->thread.pkru);
}
This appears to be writing into x86_task_fpu(tsk)->fpstate. With or
without CONFIG_X86_DEBUG_FPU, this resolves to:
((struct fpu *)((void *)(task) + sizeof(*(task))))
i.e. the memory "after task_struct" is cast to "struct fpu", and the
uses the "fpstate" pointer. How that pointer gets set looks to be
variable, but I think the one we care about here is:
fpu->fpstate = &fpu->__fpstate;
And struct fpu::__fpstate says:
struct fpstate __fpstate;
/*
* WARNING: '__fpstate' is dynamically-sized. Do not put
* anything after it here.
*/
So we're still dealing with a dynamically sized thing, even if it's not
within the literal struct task_struct -- it's still in the kmem cache,
though.
Looking at the kmem cache size, it has allocated "arch_task_struct_size"
bytes, which is calculated in fpu__init_task_struct_size():
int task_size = sizeof(struct task_struct);
task_size += sizeof(struct fpu);
/*
* Subtract off the static size of the register state.
* It potentially has a bunch of padding.
*/
task_size -= sizeof(union fpregs_state);
/*
* Add back the dynamically-calculated register state
* size.
*/
task_size += fpu_kernel_cfg.default_size;
/*
* We dynamically size 'struct fpu', so we require that
* 'state' be at the end of 'it:
*/
CHECK_MEMBER_AT_END_OF(struct fpu, __fpstate);
arch_task_struct_size = task_size;
So, this is still copying out of the kmem cache for task_struct, and the
window seems unchanged (still fpu regs). This is what the window was
before:
void fpu_thread_struct_whitelist(unsigned long *offset, unsigned long *size)
{
*offset = offsetof(struct thread_struct, fpu.__fpstate.regs);
*size = fpu_kernel_cfg.default_size;
}
And the same commit I mentioned above removed it.
I think the misunderstanding is here:
| The fpu_thread_struct_whitelist() quirk to hardened usercopy can be removed,
| now that the FPU structure is not embedded in the task struct anymore, which
| reduces text footprint a bit.
Yes, FPU is no longer in task_struct, but it IS in the kmem cache named
"task_struct", since the fpstate is still being allocated there.
Partially revert the earlier mentioned commit, along with a
recalculation of the fpstate regs location.
Fixes: cb7ca40a3882 ("x86/fpu: Make task_struct::thread constant size")
Reported-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Chang S. Bae <chang.seok.bae@intel.com>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-hardening@vger.kernel.org
Link: https://lore.kernel.org/all/20250409211127.3544993-1-mingo@kernel.org/ # Discussion #1
Link: https://lore.kernel.org/r/202505041418.F47130C4C8@keescook # Discussion #2
2025-05-04 15:30:38 -07:00
|
|
|
/* The allocation follows struct task_struct. */
|
|
|
|
*offset = sizeof(struct task_struct) - offsetof(struct task_struct, thread);
|
|
|
|
*offset += offsetof(struct fpu, __fpstate.regs);
|
2021-10-15 01:09:34 +02:00
|
|
|
*size = fpu_kernel_cfg.default_size;
|
2021-10-13 16:55:45 +02:00
|
|
|
}
|
|
|
|
|
2015-04-29 20:24:14 +02:00
|
|
|
/*
|
|
|
|
* Drops current FPU state: deactivates the fpregs and
|
|
|
|
* the fpstate. NOTE: it still leaves previous contents
|
|
|
|
* in the fpregs in the eager-FPU case.
|
|
|
|
*
|
|
|
|
* This function can be used in cases where we know that
|
|
|
|
* a state-restore is coming: either an explicit one,
|
|
|
|
* or a reschedule.
|
|
|
|
*/
|
2025-04-09 23:11:24 +02:00
|
|
|
void fpu__drop(struct task_struct *tsk)
|
2015-04-29 20:24:14 +02:00
|
|
|
{
|
2025-04-09 23:11:25 +02:00
|
|
|
struct fpu *fpu;
|
|
|
|
|
2025-05-03 16:38:56 +02:00
|
|
|
if (test_tsk_thread_flag(tsk, TIF_NEED_FPU_LOAD))
|
2025-04-09 23:11:25 +02:00
|
|
|
return;
|
|
|
|
|
|
|
|
fpu = x86_task_fpu(tsk);
|
2025-04-09 23:11:24 +02:00
|
|
|
|
2015-04-29 20:24:14 +02:00
|
|
|
preempt_disable();
|
|
|
|
|
2025-04-09 23:11:21 +02:00
|
|
|
if (fpu == x86_task_fpu(current)) {
|
2019-04-03 18:41:36 +02:00
|
|
|
/* Ignore delayed exceptions from user space */
|
|
|
|
asm volatile("1: fwait\n"
|
|
|
|
"2:\n"
|
|
|
|
_ASM_EXTABLE(1b, 2b));
|
|
|
|
fpregs_deactivate(fpu);
|
2015-04-29 20:24:14 +02:00
|
|
|
}
|
|
|
|
|
2016-06-01 10:42:20 -07:00
|
|
|
trace_x86_fpu_dropped(fpu);
|
|
|
|
|
2015-04-29 20:24:14 +02:00
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2015-04-30 11:21:59 +02:00
|
|
|
/*
|
2020-05-12 07:54:39 -07:00
|
|
|
* Clear FPU registers by setting them up from the init fpstate.
|
|
|
|
* Caller must do fpregs_[un]lock() around it.
|
2015-04-30 11:21:59 +02:00
|
|
|
*/
|
2021-06-23 14:02:02 +02:00
|
|
|
static inline void restore_fpregs_from_init_fpstate(u64 features_mask)
|
2015-04-30 11:21:59 +02:00
|
|
|
{
|
|
|
|
if (use_xsave())
|
2021-10-21 15:55:19 -07:00
|
|
|
os_xrstor(&init_fpstate, features_mask);
|
2021-06-23 14:01:54 +02:00
|
|
|
else if (use_fxsr())
|
2021-10-13 16:55:28 +02:00
|
|
|
fxrstor(&init_fpstate.regs.fxsave);
|
2016-03-11 12:32:06 +01:00
|
|
|
else
|
2021-10-13 16:55:28 +02:00
|
|
|
frstor(&init_fpstate.regs.fsave);
|
x86/pkeys: Default to a restrictive init PKRU
PKRU is the register that lets you disallow writes or all access to a given
protection key.
The XSAVE hardware defines an "init state" of 0 for PKRU: its most
permissive state, allowing access/writes to everything. Since we start off
all new processes with the init state, we start all processes off with the
most permissive possible PKRU.
This is unfortunate. If a thread is clone()'d [1] before a program has
time to set PKRU to a restrictive value, that thread will be able to write
to all data, no matter what pkey is set on it. This weakens any integrity
guarantees that we want pkeys to provide.
To fix this, we define a very restrictive PKRU to override the
XSAVE-provided value when we create a new FPU context. We choose a value
that only allows access to pkey 0, which is as restrictive as we can
practically make it.
This does not cause any practical problems with applications using
protection keys because we require them to specify initial permissions for
each key when it is allocated, which override the restrictive default.
In the end, this ensures that threads which do not know how to manage their
own pkey rights can not do damage to data which is pkey-protected.
I would have thought this was a pretty contrived scenario, except that I
heard a bug report from an MPX user who was creating threads in some very
early code before main(). It may be crazy, but folks evidently _do_ it.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-arch@vger.kernel.org
Cc: Dave Hansen <dave@sr71.net>
Cc: mgorman@techsingularity.net
Cc: arnd@arndb.de
Cc: linux-api@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: luto@kernel.org
Cc: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/20160729163021.F3C25D4A@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2016-07-29 09:30:21 -07:00
|
|
|
|
2021-06-23 14:02:11 +02:00
|
|
|
pkru_write_default();
|
2015-04-30 11:21:59 +02:00
|
|
|
}
|
|
|
|
|
2015-04-29 20:24:14 +02:00
|
|
|
/*
|
2021-06-23 14:02:13 +02:00
|
|
|
* Reset current->fpu memory state to the init values.
|
2015-04-29 08:46:26 +02:00
|
|
|
*/
|
2025-04-15 19:17:00 -07:00
|
|
|
static void fpu_reset_fpstate_regs(void)
|
2021-06-23 14:02:13 +02:00
|
|
|
{
|
2025-04-09 23:11:21 +02:00
|
|
|
struct fpu *fpu = x86_task_fpu(current);
|
2021-06-23 14:02:13 +02:00
|
|
|
|
|
|
|
fpregs_lock();
|
x86/fpu: Invalidate FPU state correctly on exec()
The thread flag TIF_NEED_FPU_LOAD indicates that the FPU saved state is
valid and should be reloaded when returning to userspace. However, the
kernel will skip doing this if the FPU registers are already valid as
determined by fpregs_state_valid(). The logic embedded there considers
the state valid if two cases are both true:
1: fpu_fpregs_owner_ctx points to the current tasks FPU state
2: the last CPU the registers were live in was the current CPU.
This is usually correct logic. A CPU’s fpu_fpregs_owner_ctx is set to
the current FPU during the fpregs_restore_userregs() operation, so it
indicates that the registers have been restored on this CPU. But this
alone doesn’t preclude that the task hasn’t been rescheduled to a
different CPU, where the registers were modified, and then back to the
current CPU. To verify that this was not the case the logic relies on the
second condition. So the assumption is that if the registers have been
restored, AND they haven’t had the chance to be modified (by being
loaded on another CPU), then they MUST be valid on the current CPU.
Besides the lazy FPU optimizations, the other cases where the FPU
registers might not be valid are when the kernel modifies the FPU register
state or the FPU saved buffer. In this case the operation modifying the
FPU state needs to let the kernel know the correspondence has been
broken. The comment in “arch/x86/kernel/fpu/context.h” has:
/*
...
* If the FPU register state is valid, the kernel can skip restoring the
* FPU state from memory.
*
* Any code that clobbers the FPU registers or updates the in-memory
* FPU state for a task MUST let the rest of the kernel know that the
* FPU registers are no longer valid for this task.
*
* Either one of these invalidation functions is enough. Invalidate
* a resource you control: CPU if using the CPU for something else
* (with preemption disabled), FPU for the current task, or a task that
* is prevented from running by the current task.
*/
However, this is not completely true. When the kernel modifies the
registers or saved FPU state, it can only rely on
__fpu_invalidate_fpregs_state(), which wipes the FPU’s last_cpu
tracking. The exec path instead relies on fpregs_deactivate(), which sets
the CPU’s FPU context to NULL. This was observed to fail to restore the
reset FPU state to the registers when returning to userspace in the
following scenario:
1. A task is executing in userspace on CPU0
- CPU0’s FPU context points to tasks
- fpu->last_cpu=CPU0
2. The task exec()’s
3. While in the kernel the task is preempted
- CPU0 gets a thread executing in the kernel (such that no other
FPU context is activated)
- Scheduler sets task’s fpu->last_cpu=CPU0 when scheduling out
4. Task is migrated to CPU1
5. Continuing the exec(), the task gets to
fpu_flush_thread()->fpu_reset_fpregs()
- Sets CPU1’s fpu context to NULL
- Copies the init state to the task’s FPU buffer
- Sets TIF_NEED_FPU_LOAD on the task
6. The task reschedules back to CPU0 before completing the exec() and
returning to userspace
- During the reschedule, scheduler finds TIF_NEED_FPU_LOAD is set
- Skips saving the registers and updating task’s fpu→last_cpu,
because TIF_NEED_FPU_LOAD is the canonical source.
7. Now CPU0’s FPU context is still pointing to the task’s, and
fpu->last_cpu is still CPU0. So fpregs_state_valid() returns true even
though the reset FPU state has not been restored.
So the root cause is that exec() is doing the wrong kind of invalidate. It
should reset fpu->last_cpu via __fpu_invalidate_fpregs_state(). Further,
fpu__drop() doesn't really seem appropriate as the task (and FPU) are not
going away, they are just getting reset as part of an exec. So switch to
__fpu_invalidate_fpregs_state().
Also, delete the misleading comment that says that either kind of
invalidate will be enough, because it’s not always the case.
Fixes: 33344368cb08 ("x86/fpu: Clean up the fpu__clear() variants")
Reported-by: Lei Wang <lei4.wang@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Lijun Pan <lijun.pan@intel.com>
Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Lijun Pan <lijun.pan@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230818170305.502891-1-rick.p.edgecombe@intel.com
2023-08-18 10:03:05 -07:00
|
|
|
__fpu_invalidate_fpregs_state(fpu);
|
2021-06-23 14:02:13 +02:00
|
|
|
/*
|
|
|
|
* This does not change the actual hardware registers. It just
|
|
|
|
* resets the memory image and sets TIF_NEED_FPU_LOAD so a
|
|
|
|
* subsequent return to usermode will reload the registers from the
|
|
|
|
* task's memory image.
|
|
|
|
*
|
|
|
|
* Do not use fpstate_init() here. Just copy init_fpstate which has
|
|
|
|
* the correct content already except for PKRU.
|
2021-06-23 14:02:22 +02:00
|
|
|
*
|
|
|
|
* PKRU handling does not rely on the xstate when restoring for
|
|
|
|
* user space as PKRU is eagerly written in switch_to() and
|
|
|
|
* flush_thread().
|
2021-06-23 14:02:13 +02:00
|
|
|
*/
|
2021-10-13 16:55:39 +02:00
|
|
|
memcpy(&fpu->fpstate->regs, &init_fpstate.regs, init_fpstate_copy_size());
|
2021-06-23 14:02:13 +02:00
|
|
|
set_thread_flag(TIF_NEED_FPU_LOAD);
|
|
|
|
fpregs_unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset current's user FPU states to the init states. current's
|
|
|
|
* supervisor states, if any, are not modified by this function. The
|
|
|
|
* caller guarantees that the XSTATE header in memory is intact.
|
|
|
|
*/
|
|
|
|
void fpu__clear_user_states(struct fpu *fpu)
|
2015-04-22 11:52:13 +02:00
|
|
|
{
|
2025-04-09 23:11:21 +02:00
|
|
|
WARN_ON_FPU(fpu != x86_task_fpu(current));
|
2015-04-23 12:46:20 +02:00
|
|
|
|
2021-06-23 14:02:13 +02:00
|
|
|
fpregs_lock();
|
|
|
|
if (!cpu_feature_enabled(X86_FEATURE_FPU)) {
|
2025-04-15 19:17:00 -07:00
|
|
|
fpu_reset_fpstate_regs();
|
2021-06-23 14:02:13 +02:00
|
|
|
fpregs_unlock();
|
2020-05-12 07:54:39 -07:00
|
|
|
return;
|
|
|
|
}
|
2016-11-17 09:11:35 -08:00
|
|
|
|
2021-06-23 14:02:13 +02:00
|
|
|
/*
|
|
|
|
* Ensure that current's supervisor states are loaded into their
|
|
|
|
* corresponding registers.
|
|
|
|
*/
|
|
|
|
if (xfeatures_mask_supervisor() &&
|
2021-10-21 15:55:19 -07:00
|
|
|
!fpregs_state_valid(fpu, smp_processor_id()))
|
|
|
|
os_xrstor_supervisor(fpu->fpstate);
|
2020-05-12 07:54:39 -07:00
|
|
|
|
2021-06-23 14:02:13 +02:00
|
|
|
/* Reset user states in registers. */
|
2021-10-15 01:09:38 +02:00
|
|
|
restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE);
|
2021-06-23 14:02:13 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now all FPU registers have their desired values. Inform the FPU
|
|
|
|
* state machine that current's FPU registers are in the hardware
|
|
|
|
* registers. The memory image does not need to be updated because
|
|
|
|
* any operation relying on it has to save the registers first when
|
|
|
|
* current's FPU is marked active.
|
|
|
|
*/
|
2020-05-12 07:54:39 -07:00
|
|
|
fpregs_mark_activate();
|
|
|
|
fpregs_unlock();
|
|
|
|
}
|
|
|
|
|
2021-06-23 14:02:12 +02:00
|
|
|
void fpu_flush_thread(void)
|
2020-05-12 07:54:39 -07:00
|
|
|
{
|
2025-04-09 23:11:21 +02:00
|
|
|
fpstate_reset(x86_task_fpu(current));
|
2025-04-15 19:17:00 -07:00
|
|
|
fpu_reset_fpstate_regs();
|
2015-04-22 11:52:13 +02:00
|
|
|
}
|
2019-04-03 18:41:52 +02:00
|
|
|
/*
|
|
|
|
* Load FPU context before returning to userspace.
|
|
|
|
*/
|
|
|
|
void switch_fpu_return(void)
|
|
|
|
{
|
|
|
|
if (!static_cpu_has(X86_FEATURE_FPU))
|
|
|
|
return;
|
|
|
|
|
2021-06-23 14:02:14 +02:00
|
|
|
fpregs_restore_userregs();
|
2019-04-03 18:41:52 +02:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(switch_fpu_return);
|
|
|
|
|
2023-06-12 17:10:51 -07:00
|
|
|
void fpregs_lock_and_load(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* fpregs_lock() only disables preemption (mostly). So modifying state
|
|
|
|
* in an interrupt could screw up some in progress fpregs operation.
|
|
|
|
* Warn about it.
|
|
|
|
*/
|
|
|
|
WARN_ON_ONCE(!irq_fpu_usable());
|
|
|
|
WARN_ON_ONCE(current->flags & PF_KTHREAD);
|
|
|
|
|
|
|
|
fpregs_lock();
|
|
|
|
|
|
|
|
fpregs_assert_state_consistent();
|
|
|
|
|
|
|
|
if (test_thread_flag(TIF_NEED_FPU_LOAD))
|
|
|
|
fpregs_restore_userregs();
|
|
|
|
}
|
|
|
|
|
2019-04-03 18:41:52 +02:00
|
|
|
#ifdef CONFIG_X86_DEBUG_FPU
|
|
|
|
/*
|
|
|
|
* If current FPU state according to its tracking (loaded FPU context on this
|
|
|
|
* CPU) is not valid then we must have TIF_NEED_FPU_LOAD set so the context is
|
|
|
|
* loaded on return to userland.
|
|
|
|
*/
|
|
|
|
void fpregs_assert_state_consistent(void)
|
|
|
|
{
|
2025-04-09 23:11:21 +02:00
|
|
|
struct fpu *fpu = x86_task_fpu(current);
|
2019-04-03 18:41:52 +02:00
|
|
|
|
|
|
|
if (test_thread_flag(TIF_NEED_FPU_LOAD))
|
|
|
|
return;
|
|
|
|
|
|
|
|
WARN_ON_FPU(!fpregs_state_valid(fpu, smp_processor_id()));
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(fpregs_assert_state_consistent);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
void fpregs_mark_activate(void)
|
|
|
|
{
|
2025-04-09 23:11:21 +02:00
|
|
|
struct fpu *fpu = x86_task_fpu(current);
|
2019-04-03 18:41:52 +02:00
|
|
|
|
|
|
|
fpregs_activate(fpu);
|
|
|
|
fpu->last_cpu = smp_processor_id();
|
|
|
|
clear_thread_flag(TIF_NEED_FPU_LOAD);
|
|
|
|
}
|
|
|
|
|
2015-04-30 09:29:38 +02:00
|
|
|
/*
|
|
|
|
* x87 math exception handling:
|
|
|
|
*/
|
|
|
|
|
|
|
|
int fpu__exception_code(struct fpu *fpu, int trap_nr)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (trap_nr == X86_TRAP_MF) {
|
|
|
|
unsigned short cwd, swd;
|
|
|
|
/*
|
|
|
|
* (~cwd & swd) will mask out exceptions that are not set to unmasked
|
|
|
|
* status. 0x3f is the exception bits in these regs, 0x200 is the
|
|
|
|
* C1 reg you need in case of a stack fault, 0x040 is the stack
|
|
|
|
* fault bit. We should only be taking one exception at a time,
|
|
|
|
* so if this combination doesn't produce any single exception,
|
|
|
|
* then we have a bad program that isn't synchronizing its FPU usage
|
|
|
|
* and it will suffer the consequences since we won't be able to
|
2016-04-05 08:29:55 +02:00
|
|
|
* fully reproduce the context of the exception.
|
2015-04-30 09:29:38 +02:00
|
|
|
*/
|
2016-04-05 08:29:55 +02:00
|
|
|
if (boot_cpu_has(X86_FEATURE_FXSR)) {
|
2021-10-13 16:55:39 +02:00
|
|
|
cwd = fpu->fpstate->regs.fxsave.cwd;
|
|
|
|
swd = fpu->fpstate->regs.fxsave.swd;
|
2016-04-05 08:29:55 +02:00
|
|
|
} else {
|
2021-10-13 16:55:39 +02:00
|
|
|
cwd = (unsigned short)fpu->fpstate->regs.fsave.cwd;
|
|
|
|
swd = (unsigned short)fpu->fpstate->regs.fsave.swd;
|
2016-04-05 08:29:55 +02:00
|
|
|
}
|
2015-04-30 09:29:38 +02:00
|
|
|
|
|
|
|
err = swd & ~cwd;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The SIMD FPU exceptions are handled a little differently, as there
|
|
|
|
* is only a single status/control register. Thus, to determine which
|
|
|
|
* unmasked exception was caught we must mask the exception mask bits
|
|
|
|
* at 0x1f80, and then use these to mask the exception bits at 0x3f.
|
|
|
|
*/
|
2016-04-05 08:29:55 +02:00
|
|
|
unsigned short mxcsr = MXCSR_DEFAULT;
|
|
|
|
|
|
|
|
if (boot_cpu_has(X86_FEATURE_XMM))
|
2021-10-13 16:55:39 +02:00
|
|
|
mxcsr = fpu->fpstate->regs.fxsave.mxcsr;
|
2016-04-05 08:29:55 +02:00
|
|
|
|
2015-04-30 09:29:38 +02:00
|
|
|
err = ~(mxcsr >> 7) & mxcsr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err & 0x001) { /* Invalid op */
|
|
|
|
/*
|
|
|
|
* swd & 0x240 == 0x040: Stack Underflow
|
|
|
|
* swd & 0x240 == 0x240: Stack Overflow
|
|
|
|
* User must clear the SF bit (0x40) if set
|
|
|
|
*/
|
|
|
|
return FPE_FLTINV;
|
|
|
|
} else if (err & 0x004) { /* Divide by Zero */
|
|
|
|
return FPE_FLTDIV;
|
|
|
|
} else if (err & 0x008) { /* Overflow */
|
|
|
|
return FPE_FLTOVF;
|
|
|
|
} else if (err & 0x012) { /* Denormal, Underflow */
|
|
|
|
return FPE_FLTUND;
|
|
|
|
} else if (err & 0x020) { /* Precision */
|
|
|
|
return FPE_FLTRES;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're using IRQ 13, or supposedly even some trap
|
|
|
|
* X86_TRAP_MF implementations, it's possible
|
|
|
|
* we get a spurious trap, which is not an error.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
2022-06-08 09:47:47 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize register state that may prevent from entering low-power idle.
|
|
|
|
* This function will be invoked from the cpuidle driver only when needed.
|
|
|
|
*/
|
2023-01-12 20:43:33 +01:00
|
|
|
noinstr void fpu_idle_fpregs(void)
|
2022-06-08 09:47:47 -07:00
|
|
|
{
|
|
|
|
/* Note: AMX_TILE being enabled implies XGETBV1 support */
|
|
|
|
if (cpu_feature_enabled(X86_FEATURE_AMX_TILE) &&
|
|
|
|
(xfeatures_in_use() & XFEATURE_MASK_XTILE)) {
|
|
|
|
tile_release();
|
2023-01-12 20:43:33 +01:00
|
|
|
__this_cpu_write(fpu_fpregs_owner_ctx, NULL);
|
2022-06-08 09:47:47 -07:00
|
|
|
}
|
|
|
|
}
|