From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: [PATCH v4 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly
Date: Fri, 4 Mar 2016 10:12:33 -0800 [thread overview]
Message-ID: <b4b6fd6f2b928474748abb3d842aef025cbd10da.1457038929.git.yu-cheng.yu@intel.com> (raw)
In-Reply-To: <cover.1457038929.git.yu-cheng.yu@intel.com>
In-Reply-To: <cover.1457038929.git.yu-cheng.yu@intel.com>
XSAVES is a kernel instruction and uses a compacted format. When
working with user space, the kernel should provide standard-format,
non-supervisor state data. We cannot do __copy_to_user() from a compacted-
format kernel xstate area to a signal frame.
Note that the path to copy_fpstate_to_sigframe() does currently check if
the thread has used FPU, but add a WARN_ONCE() there to detect any
potential mis-use.
Dave Hansen proposes this method to simplify copy xstate directly to user.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
arch/x86/kernel/fpu/signal.c | 41 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
index 0fbf60c..09945f1 100644
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -130,6 +130,45 @@ static inline int copy_fpregs_to_sigframe(struct xregs_state __user *buf)
return err;
}
+static int may_copy_fpregs_to_sigframe(void)
+{
+ /*
+ * In signal handling path, the kernel already checks if
+ * FPU instructions have been used before it calls
+ * copy_fpstate_to_sigframe(). We check this here again
+ * to detect any potential mis-use and saving invalid
+ * register values directly to a signal frame.
+ */
+ WARN_ONCE(!current->thread.fpu.fpstate_active,
+ "direct FPU save with no math use\n");
+
+ /*
+ * In the case that we are using a compacted kernel
+ * xsave area, we can not copy the thread.fpu.state
+ * directly to userspace and *must* save it from the
+ * registers directly.
+ */
+ if (boot_cpu_has(X86_FEATURE_XSAVES))
+ return 1;
+
+ /*
+ * fpregs_active() means "Can I use the FPU hardware
+ * without taking a device-not-available exception?" This
+ * means that saving the registers directly will be
+ * cheaper than copying their contents out of
+ * thread.fpu.state.
+ *
+ * Note that fpregs_active() is inherently racy and may
+ * become false at any time. If this race happens, we
+ * will take a harmless device-not-available exception
+ * when we attempt the FPU save instruction.
+ */
+ if (fpregs_active())
+ return 1;
+
+ return 0;
+}
+
/*
* Save the fpu, extended register state to the user signal frame.
*
@@ -167,7 +206,7 @@ int copy_fpstate_to_sigframe(void __user *buf, void __user *buf_fx, int size)
sizeof(struct user_i387_ia32_struct), NULL,
(struct _fpstate_32 __user *) buf) ? -1 : 1;
- if (fpregs_active()) {
+ if (may_copy_fpregs_to_sigframe()) {
/* Save the live register state to the user directly. */
if (copy_fpregs_to_sigframe(buf_fx))
return -1;
--
1.9.1
next prev parent reply other threads:[~2016-03-04 18:17 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 18:12 [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Yu-cheng Yu
2016-03-04 18:12 ` [PATCH v4 01/10] x86/xsaves: Define and use user_xstate_size for xstate size in signal context Yu-cheng Yu
2016-03-04 18:12 ` [PATCH v4 02/10] x86/xsaves: Rename xstate_size to kernel_xstate_size to explicitly distinguish xstate size in kernel from user space Yu-cheng Yu
2016-03-04 18:12 ` [PATCH v4 03/10] x86/xsaves: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization Yu-cheng Yu
2016-03-04 18:12 ` Yu-cheng Yu [this message]
2016-04-29 20:09 ` [PATCH v4 04/10] x86/xsaves: Introduce a new check that allows correct xstates copy from kernel to user directly Dave Hansen
2016-04-29 22:43 ` Yu-cheng Yu
2016-04-30 0:36 ` Dave Hansen
2016-05-02 15:57 ` Yu-cheng Yu
2016-05-02 16:06 ` Dave Hansen
2016-05-02 16:34 ` Yu-cheng Yu
2016-05-02 16:43 ` Dave Hansen
2016-05-02 17:19 ` Yu-cheng Yu
2016-05-02 17:33 ` Dave Hansen
2016-05-02 21:18 ` Yu-cheng Yu
2016-05-02 21:24 ` Yu-cheng Yu
2016-05-02 21:32 ` Dave Hansen
2016-05-02 22:17 ` Yu-cheng Yu
2016-05-02 22:37 ` Dave Hansen
2016-03-04 18:12 ` [PATCH v4 05/10] x86/xsaves: Align xstate components according to CPUID Yu-cheng Yu
2016-04-29 20:11 ` Dave Hansen
2016-03-04 18:12 ` [PATCH v4 06/10] x86/xsaves: Supervisor state component offset Yu-cheng Yu
2016-03-04 18:12 ` [PATCH v4 07/10] x86/xsaves: Fix PTRACE frames for XSAVES Yu-cheng Yu
2016-04-29 20:16 ` Dave Hansen
2016-04-29 20:38 ` Borislav Petkov
2016-04-29 20:40 ` Dave Hansen
2016-04-29 20:46 ` Borislav Petkov
2016-04-29 20:25 ` Dave Hansen
2016-04-29 22:30 ` Yu-cheng Yu
2016-04-29 22:36 ` Dave Hansen
2016-04-29 22:38 ` Yu-cheng Yu
2016-03-04 18:12 ` [PATCH v4 08/10] x86/xsaves: Fix XSTATE component offset print out Yu-cheng Yu
2016-04-29 20:26 ` Dave Hansen
2016-03-04 18:12 ` [PATCH v4 09/10] x86/xsaves: Fix xstate_offsets, xstate_sizes for legacy components Yu-cheng Yu
2016-04-29 20:28 ` Dave Hansen
2016-04-29 22:07 ` Yu-cheng Yu
2016-04-29 22:13 ` Dave Hansen
2016-04-29 22:15 ` Yu-cheng Yu
2016-03-04 18:12 ` [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES Yu-cheng Yu
2016-04-29 20:32 ` Dave Hansen
2016-04-29 23:12 ` Yu-cheng Yu
2016-04-30 0:40 ` Dave Hansen
2016-05-02 16:11 ` Yu-cheng Yu
2016-05-04 22:15 ` Dave Hansen
2016-05-04 22:21 ` Yu-cheng Yu
2016-05-04 22:41 ` Dave Hansen
2016-05-04 22:46 ` Yu-cheng Yu
2016-05-04 22:46 ` Dave Hansen
2016-04-29 18:09 ` [PATCH v4 0/10] x86/xsaves: Fix XSAVES known issues Dave Hansen
2016-04-29 19:43 ` Ingo Molnar
2016-04-29 19:57 ` Yu-cheng Yu
2016-04-29 20:03 ` Dave Hansen
2016-04-29 20:07 ` Yu-cheng Yu
2016-04-29 20:25 ` Andy Lutomirski
2016-04-29 20:40 ` Dave Hansen
2016-04-29 20:49 ` Andy Lutomirski
2016-04-29 22:42 ` Dave Hansen
2016-04-30 7:53 ` Ingo Molnar
2016-05-02 16:28 ` Dave Hansen
2016-05-02 18:32 ` Ingo Molnar
2016-04-29 20:37 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b4b6fd6f2b928474748abb3d842aef025cbd10da.1457038929.git.yu-cheng.yu@intel.com \
--to=yu-cheng.yu@intel.com \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=ravi.v.shankar@intel.com \
--cc=sai.praneeth.prakhya@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®