From: Dave Hansen <dave@sr71.net>
To: linux-kernel@vger.kernel.org
Cc: x86@kernel.org, tglx@linutronix.de, Dave Hansen <dave@sr71.net>,
dave.hansen@linux.intel.com
Subject: [PATCH 13/17] x86, mpx: new directory entry to addr helper
Date: Wed, 22 Apr 2015 11:27:47 -0700 [thread overview]
Message-ID: <20150422182747.44CBC2AB@viggo.jf.intel.com> (raw)
In-Reply-To: <20150422182729.0512E57D@viggo.jf.intel.com>
From: Dave Hansen <dave.hansen@linux.intel.com>
Currently, to get from a bounds directory entry to the virtual
address of a bounds table, we simply mask off a few low bits.
However, the set of bits we mask off is different for 32 and
64-bit binaries.
This breaks the operation out in to a helper function and also
adds a temporary variable to store the result until we are
sure we are returning one.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
---
b/arch/x86/include/asm/mpx.h | 1 -
b/arch/x86/mm/mpx.c | 41 ++++++++++++++++++++++++++++++++++-------
2 files changed, 34 insertions(+), 8 deletions(-)
diff -puN arch/x86/include/asm/mpx.h~mpx-new-entry-to-addr-helper arch/x86/include/asm/mpx.h
--- a/arch/x86/include/asm/mpx.h~mpx-new-entry-to-addr-helper 2015-04-22 11:16:22.624018995 -0700
+++ b/arch/x86/include/asm/mpx.h 2015-04-22 11:16:22.629019220 -0700
@@ -45,7 +45,6 @@
#define MPX_BNDSTA_TAIL 2
#define MPX_BNDCFG_TAIL 12
#define MPX_BNDSTA_ADDR_MASK (~((1UL<<MPX_BNDSTA_TAIL)-1))
-#define MPX_BT_ADDR_MASK (~((1UL<<MPX_BD_ENTRY_TAIL)-1))
#define MPX_BNDCFG_ADDR_MASK (~((1UL<<MPX_BNDCFG_TAIL)-1))
#define MPX_BNDSTA_ERROR_CODE 0x3
diff -puN arch/x86/mm/mpx.c~mpx-new-entry-to-addr-helper arch/x86/mm/mpx.c
--- a/arch/x86/mm/mpx.c~mpx-new-entry-to-addr-helper 2015-04-22 11:16:22.626019085 -0700
+++ b/arch/x86/mm/mpx.c 2015-04-22 11:16:22.630019266 -0700
@@ -578,29 +578,55 @@ static int mpx_resolve_fault(long __user
return 0;
}
+static unsigned long mpx_bd_entry_to_bt_addr(struct mm_struct *mm,
+ unsigned long bd_entry)
+{
+ unsigned long bt_addr = bd_entry;
+ int align_to_bytes;
+ /*
+ * Bit 0 in a bt_entry is always the valid bit.
+ */
+ bt_addr &= ~MPX_BD_ENTRY_VALID_FLAG;
+ /*
+ * Tables are naturally aligned at 8-byte boundaries
+ * on 64-bit and 4-byte boundaries on 32-bit. The
+ * documentation makes it appear that the low bits
+ * are ignored by the hardware, so we do the same.
+ */
+ if (is_64bit_mm(mm))
+ align_to_bytes = 8;
+ else
+ align_to_bytes = 4;
+ bt_addr &= ~(align_to_bytes-1);
+ return bt_addr;
+}
+
/*
* Get the base of bounds tables pointed by specific bounds
* directory entry.
*/
static int get_bt_addr(struct mm_struct *mm,
- long __user *bd_entry, unsigned long *bt_addr)
+ long __user *bd_entry_ptr,
+ unsigned long *bt_addr_result)
{
int ret;
int valid_bit;
+ unsigned long bd_entry;
+ unsigned long bt_addr;
- if (!access_ok(VERIFY_READ, (bd_entry), sizeof(*bd_entry)))
+ if (!access_ok(VERIFY_READ, (bd_entry_ptr), sizeof(*bd_entry_ptr)))
return -EFAULT;
while (1) {
int need_write = 0;
pagefault_disable();
- ret = get_user(*bt_addr, bd_entry);
+ ret = get_user(bd_entry, bd_entry_ptr);
pagefault_enable();
if (!ret)
break;
if (ret == -EFAULT)
- ret = mpx_resolve_fault(bd_entry, need_write);
+ ret = mpx_resolve_fault(bd_entry_ptr, need_write);
/*
* If we could not resolve the fault, consider it
* userspace's fault and error out.
@@ -609,8 +635,8 @@ static int get_bt_addr(struct mm_struct
return ret;
}
- valid_bit = *bt_addr & MPX_BD_ENTRY_VALID_FLAG;
- *bt_addr &= MPX_BT_ADDR_MASK;
+ valid_bit = bd_entry & MPX_BD_ENTRY_VALID_FLAG;
+ bt_addr = mpx_bd_entry_to_bt_addr(mm, bd_entry);
/*
* When the kernel is managing bounds tables, a bounds directory
@@ -619,7 +645,7 @@ static int get_bt_addr(struct mm_struct
* data in the address field, we know something is wrong. This
* -EINVAL return will cause a SIGSEGV.
*/
- if (!valid_bit && *bt_addr)
+ if (!valid_bit && bt_addr)
return -EINVAL;
/*
* Do we have an completely zeroed bt entry? That is OK. It
@@ -630,6 +656,7 @@ static int get_bt_addr(struct mm_struct
if (!valid_bit)
return -ENOENT;
+ *bt_addr_result = bt_addr;
return 0;
}
_
next prev parent reply other threads:[~2015-04-22 18:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-22 18:27 [PATCH 00/17] x86, mpx updates for 4.2 (take 5) Dave Hansen
2015-04-22 18:27 ` [PATCH 01/17] x86, fpu: wrap get_xsave_addr() to make it safer Dave Hansen
2015-04-25 9:31 ` Borislav Petkov
2015-05-05 17:27 ` Borislav Petkov
2015-05-08 17:42 ` Dave Hansen
2015-04-22 18:27 ` [PATCH 02/17] x86, mpx: use new tsk_get_xsave_addr() Dave Hansen
2015-04-22 19:18 ` Yu, Fenghua
2015-04-22 19:32 ` Dave Hansen
2015-04-22 21:21 ` Yu, Fenghua
2015-04-22 18:27 ` [PATCH 03/17] x86, mpx: trace #BR exceptions Dave Hansen
2015-04-22 18:27 ` [PATCH 04/17] x86, mpx: trace entry to bounds exception paths Dave Hansen
2015-04-22 18:27 ` [PATCH 05/17] x86, mpx: trace ranged MPX operations Dave Hansen
2015-04-22 18:27 ` [PATCH 06/17] x86, mpx: trace allocation of new bounds tables Dave Hansen
2015-04-22 18:27 ` [PATCH 07/17] x86, mpx: boot-time disable Dave Hansen
2015-04-22 18:27 ` [PATCH 08/17] x86: make is_64bit_mm() widely available Dave Hansen
2015-04-22 18:27 ` [PATCH 09/17] x86: make __VIRTUAL_MASK safe to use on 32 bit Dave Hansen
2015-04-22 18:27 ` [PATCH 10/17] x86, mpx: we do not allocate the bounds directory Dave Hansen
2015-04-22 18:27 ` [PATCH 11/17] x86, mpx: remove redundant MPX_BNDCFG_ADDR_MASK Dave Hansen
2015-04-22 18:27 ` [PATCH 12/17] x86, mpx: Add temporary variable to reduce masking Dave Hansen
2015-04-22 18:27 ` Dave Hansen [this message]
2015-04-22 18:27 ` [PATCH 14/17] x86, mpx: do 32-bit-only cmpxchg for 32-bit apps Dave Hansen
2015-04-22 18:27 ` [PATCH 15/17] x86, mpx: support 32-bit binaries on 64-bit kernel Dave Hansen
2015-04-22 18:27 ` [PATCH 16/17] x86, mpx: allow mixed binaries again Dave Hansen
2015-04-22 18:27 ` [PATCH 17/17] x86, mpx: cleanup: do not pass task around when unnecessary 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=20150422182747.44CBC2AB@viggo.jf.intel.com \
--to=dave@sr71.net \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.