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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox