| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20150827171108.3AE5C49B@viggo.jf.intel.com>
Date: Thu, 27 Aug 2015 10:11:08 -0700
From: Dave Hansen <dave@...1.net>
To: dave@...1.net
Cc: dave.hansen@...ux.intel.com, mingo@...hat.com, x86@...nel.org,
bp@...en8.de, fenghua.yu@...el.com, tim.c.chen@...ux.intel.com,
linux-kernel@...r.kernel.org
Subject: [PATCH 06/11] x86, fpu: rework MPX 'xstate' types
From: Dave Hansen <dave.hansen@...ux.intel.com>
MPX includes two separate "extended state components". There is
no real need to have an 'mpx_struct' because we never really
manage the states together.
We also separate out the actual data in 'mpx_bndcsr_state' from
the padding. We will shortly be checking the state sizes against
our structures and need them to match. For consistency, we also
ensure to prefix these types with 'mpx_'.
Lastly, we add some comments to mirror some of the descriptions
in the Intel documents (SDM) of the various state components.
Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: x86@...nel.org
Cc: Borislav Petkov <bp@...en8.de>
Cc: Fenghua Yu <fenghua.yu@...el.com>
Cc: Tim Chen <tim.c.chen@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org
---
b/arch/x86/include/asm/fpu/types.h | 36 +++++++++++++++++++++++++++---------
b/arch/x86/include/asm/trace/mpx.h | 7 ++++---
b/arch/x86/kernel/traps.c | 2 +-
b/arch/x86/mm/mpx.c | 9 +++++----
4 files changed, 37 insertions(+), 17 deletions(-)
diff -puN arch/x86/include/asm/fpu/types.h~x86-fpu-rework-mpx-types arch/x86/include/asm/fpu/types.h
--- a/arch/x86/include/asm/fpu/types.h~x86-fpu-rework-mpx-types 2015-08-27 10:08:03.093703606 -0700
+++ b/arch/x86/include/asm/fpu/types.h 2015-08-27 10:08:03.101703971 -0700
@@ -139,20 +139,37 @@ struct ymmh_struct {
};
/* Intel MPX support: */
-struct bndreg {
+
+struct mpx_bndreg {
u64 lower_bound;
u64 upper_bound;
} __packed;
+/*
+ * State component 3 is used for the 4 128-bit bounds registers
+ */
+struct mpx_bndreg_state {
+ struct mpx_bndreg bndreg[4];
+} __packed;
-struct bndcsr {
- u64 bndcfgu;
- u64 bndstatus;
+/*
+ * State component 4 is used for the 64-bit user-mode MPX
+ * configuration register BNDCFGU and the 64-bit MPX status
+ * register BNDSTATUS. We call the pair "BNDCSR".
+ */
+struct mpx_bndcsr {
+ u64 bndcfgu;
+ u64 bndstatus;
} __packed;
-struct mpx_struct {
- struct bndreg bndreg[4];
- struct bndcsr bndcsr;
-};
+/*
+ * The BNDCSR state is padded out to be 64-bytes in size.
+ */
+struct mpx_bndcsr_state {
+ union {
+ struct mpx_bndcsr bndcsr;
+ u8 pad_to_64_bytes[64];
+ };
+} __packed;
struct xstate_header {
u64 xfeatures;
@@ -162,7 +179,8 @@ struct xstate_header {
/* New processor state extensions should be added here: */
#define XSTATE_RESERVE (sizeof(struct ymmh_struct) + \
- sizeof(struct mpx_struct) )
+ sizeof(struct mpx_bndreg_state) + \
+ sizeof(struct mpx_bndcsr_state) )
/*
* This is our most modern FPU state format, as saved by the XSAVE
* and restored by the XRSTOR instructions.
diff -puN arch/x86/include/asm/trace/mpx.h~x86-fpu-rework-mpx-types arch/x86/include/asm/trace/mpx.h
--- a/arch/x86/include/asm/trace/mpx.h~x86-fpu-rework-mpx-types 2015-08-27 10:08:03.094703652 -0700
+++ b/arch/x86/include/asm/trace/mpx.h 2015-08-27 10:08:03.101703971 -0700
@@ -11,7 +11,7 @@
TRACE_EVENT(mpx_bounds_register_exception,
TP_PROTO(void *addr_referenced,
- const struct bndreg *bndreg),
+ const struct mpx_bndreg *bndreg),
TP_ARGS(addr_referenced, bndreg),
TP_STRUCT__entry(
@@ -44,7 +44,7 @@ TRACE_EVENT(mpx_bounds_register_exceptio
TRACE_EVENT(bounds_exception_mpx,
- TP_PROTO(const struct bndcsr *bndcsr),
+ TP_PROTO(const struct mpx_bndcsr *bndcsr),
TP_ARGS(bndcsr),
TP_STRUCT__entry(
@@ -116,7 +116,8 @@ TRACE_EVENT(mpx_new_bounds_table,
/*
* This gets used outside of MPX-specific code, so we need a stub.
*/
-static inline void trace_bounds_exception_mpx(const struct bndcsr *bndcsr)
+static inline
+void trace_bounds_exception_mpx(const struct mpx_bndcsr *bndcsr)
{
}
diff -puN arch/x86/kernel/traps.c~x86-fpu-rework-mpx-types arch/x86/kernel/traps.c
--- a/arch/x86/kernel/traps.c~x86-fpu-rework-mpx-types 2015-08-27 10:08:03.096703743 -0700
+++ b/arch/x86/kernel/traps.c 2015-08-27 10:08:03.102704016 -0700
@@ -372,7 +372,7 @@ dotraplinkage void do_double_fault(struc
dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
{
enum ctx_state prev_state;
- const struct bndcsr *bndcsr;
+ const struct mpx_bndcsr *bndcsr;
siginfo_t *info;
prev_state = exception_enter();
diff -puN arch/x86/mm/mpx.c~x86-fpu-rework-mpx-types arch/x86/mm/mpx.c
--- a/arch/x86/mm/mpx.c~x86-fpu-rework-mpx-types 2015-08-27 10:08:03.098703834 -0700
+++ b/arch/x86/mm/mpx.c 2015-08-27 10:08:03.102704016 -0700
@@ -274,7 +274,8 @@ bad_opcode:
*/
siginfo_t *mpx_generate_siginfo(struct pt_regs *regs)
{
- const struct bndreg *bndregs, *bndreg;
+ const struct mpx_bndreg_state *bndregs;
+ const struct mpx_bndreg *bndreg;
siginfo_t *info = NULL;
struct insn insn;
uint8_t bndregno;
@@ -301,7 +302,7 @@ siginfo_t *mpx_generate_siginfo(struct p
goto err_out;
}
/* now go select the individual register in the set of 4 */
- bndreg = &bndregs[bndregno];
+ bndreg = &bndregs->bndreg[bndregno];
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info) {
@@ -343,7 +344,7 @@ err_out:
static __user void *mpx_get_bounds_dir(void)
{
- const struct bndcsr *bndcsr;
+ const struct mpx_bndcsr *bndcsr;
if (!cpu_feature_enabled(X86_FEATURE_MPX))
return MPX_INVALID_BOUNDS_DIR;
@@ -526,7 +527,7 @@ out_unmap:
static int do_mpx_bt_fault(void)
{
unsigned long bd_entry, bd_base;
- const struct bndcsr *bndcsr;
+ const struct mpx_bndcsr *bndcsr;
struct mm_struct *mm = current->mm;
bndcsr = get_xsave_field_ptr(XSTATE_BNDCSR);
_
--
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