[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150519062529.9636B111@viggo.jf.intel.com>
Date: Mon, 18 May 2015 23:25:29 -0700
From: Dave Hansen <dave@...1.net>
To: linux-kernel@...r.kernel.org
Cc: x86@...nel.org, tglx@...utronix.de, Dave Hansen <dave@...1.net>,
dave.hansen@...ux.intel.com, oleg@...hat.com, bp@...en8.de,
riel@...hat.com, sbsiddha@...il.com, luto@...capital.net,
mingo@...hat.com, hpa@...or.com, fenghua.yu@...el.com
Subject: [PATCH 02/19] x86, fpu: Wrap get_xsave_addr() to make it safer
From: Dave Hansen <dave.hansen@...ux.intel.com>
The MPX code appears to be saving off the FPU in an unsafe
way. It does not disable preemption or ensure that the
FPU state has been allocated. All of the preemption safety
comes from the unfortunatley-named 'unlazy_fpu()'.
This patch introduces a new helper which will do both of
those things internally.
Note that this requires a patch from Oleg in order to work
properly. It is currently in tip/x86/fpu.
> commit f893959b0898bd876673adbeb6798bdf25c034d7
> Author: Oleg Nesterov <oleg@...hat.com>
> Date: Fri Mar 13 18:30:30 2015 +0100
>
> x86/fpu: Don't abuse drop_init_fpu() in flush_thread()
Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Oleg Nesterov <oleg@...hat.com>
Cc: bp@...en8.de
Cc: Rik van Riel <riel@...hat.com>
Cc: Suresh Siddha <sbsiddha@...il.com>
Cc: Andy Lutomirski <luto@...capital.net>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: Fenghua Yu <fenghua.yu@...el.com>
Cc: the arch/x86 maintainers <x86@...nel.org>
---
Changes from v21:
* add comments about preemption
* rename helper to get_xsave_field_ptr()
Changes from "v19":
* remove 'tsk' argument to get_xsave_addr() since the code
can only realistically work on 'current', and fix up the
comment a bit to match.
Changes from "v17":
* fix s/xstate/xsave_field/ in the function comment
* remove EXPORT_SYMBOL_GPL()
---
b/arch/x86/include/asm/xsave.h | 1 +
b/arch/x86/kernel/xsave.c | 33 +++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff -puN arch/x86/include/asm/xsave.h~tsk_get_xsave_addr arch/x86/include/asm/xsave.h
--- a/arch/x86/include/asm/xsave.h~tsk_get_xsave_addr 2015-05-18 17:48:58.222390639 -0700
+++ b/arch/x86/include/asm/xsave.h 2015-05-18 17:48:58.227390864 -0700
@@ -252,6 +252,7 @@ static inline int xrestore_user(struct x
}
void *get_xsave_addr(struct xsave_struct *xsave, int xstate);
+void *get_xsave_field_ptr(int xstate_field);
void setup_xstate_comp(void);
#endif
diff -puN arch/x86/kernel/xsave.c~tsk_get_xsave_addr arch/x86/kernel/xsave.c
--- a/arch/x86/kernel/xsave.c~tsk_get_xsave_addr 2015-05-18 17:48:58.224390729 -0700
+++ b/arch/x86/kernel/xsave.c 2015-05-18 17:48:58.227390864 -0700
@@ -750,3 +750,36 @@ void *get_xsave_addr(struct xsave_struct
return (void *)xsave + xstate_comp_offsets[feature_nr];
}
EXPORT_SYMBOL_GPL(get_xsave_addr);
+
+/*
+ * This wraps up the common operations that need to occur when retrieving
+ * data from xsave state. It first ensures that the current task was
+ * using the FPU and retrieves the data in to a buffer. It then calculates
+ * the offset of the requested field in the buffer.
+ *
+ * This function is safe to call whether the FPU is in use or not.
+ *
+ * Note that this only works on the current task.
+ *
+ * Inputs:
+ * @xsave_field: state which is defined in xsave.h (e.g. XSTATE_FP,
+ * XSTATE_SSE, etc...)
+ * Output:
+ * address of the state in the xsave area or NULL if the field
+ * is not present or is in its 'init state'.
+ */
+void *get_xsave_field_ptr(int xsave_field)
+{
+ union thread_xstate *xstate;
+
+ if (!tsk_used_math(current))
+ return NULL;
+ /*
+ * unlazy_fpu() is poorly named and will actually
+ * save the xstate off in to the memory buffer.
+ */
+ unlazy_fpu(current);
+ xstate = current->thread.fpu.state;
+
+ return get_xsave_addr(&xstate->xsave, xsave_field);
+}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists