Intel MPX support
Subsystems (11)
v11 cover Intel MPX support
From: Dave Hansen <[email protected]>
Changes since v10:
* get rid of some generic #ifdefs and add mpx_mm_init(mm)
* add comment about reasons for doing xsaves
* Cleanups in "on-demand allocation" patch, and add a missing return
* Changes in some of the unmapping code error handling. Make it more strict not to ever ignore unmapping errors.
* Add the get_xsave_addr() to one spot which was missed
----
Why am I cc'ing you on this?
mips/ia64 folks: the only patch that applies to you is the'
'struct siginfo' one.
mm folks: the most interesting patches are the last 2 (excluding
the Documentation/ one).
---
We (Intel) are also trying to get some code merged in to GCC for MPX. It will be calling the new prctl()s introduced in this set. We need to get those numbers locked down an reserved in the kernel before we push the GCC code, though.
This currently requires booting with 'noxsaves' to work around what I presume is an issue in the x86 'xsaves' code. I'll work with the folks responsible to get it fixed up properlye
---
This patch set adds support for the Memory Protection eXtensions (MPX) feature found in future Intel processors. MPX is used in conjunction with compiler changes to check memory references, and can be used to catch buffer overflow or underflow.
For MPX to work, changes are required in the kernel, binutils and compiler. No source changes are required for applications, just a recompile.
There are a lot of moving parts of this to all work right:
=== Example Compiler / Application / Kernel Interaction ==
1. Application developer compiles with -fmpx. The compiler will add the instrumentation as well as some setup code called early after the app starts. New instruction prefixes are noops for old CPUs.
2. That setup code allocates (virtual) space for the "bounds directory", points the "bndcfgu" register to the directory and notifies the kernel (via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using MPX.
3. The kernel detects that the CPU has MPX, allows the new prctl() to succeed, and notes the location of the bounds directory. Userspace is expected to keep the bounds directory at that location. We note it instead of reading it each time because the 'xsave' operation needed to access the bounds directory register is an expensive operation.
4. If the application needs to spill bounds out of the 4 registers, it issues a bndstx instruction. Since the bounds directory is empty at this point, a bounds fault (#BR) is raised, the kernel allocates a bounds table (in the user address space) and makes the relevant entry in the bounds directory point to the new table. [1]
5. If the application violates the bounds specified in the bounds registers, a separate kind of #BR is raised which will deliver a signal with information about the violation in the 'struct siginfo'.
6. Whenever memory is freed, we know that it can no longer contain valid pointers, and we attempt to free the associated space in the bounds tables. If an entire table becomes unused, we will attempt to free the table and remove the entry in the directory.
To summarize, there are essentially three things interacting here:
GCC with -fmpx:
* enables annotation of code with MPX instructions and prefixes
* inserts code early in the application to call in to the "gcc runtime"
GCC MPX Runtime:
* Checks for hardware MPX support in cpuid leaf
* allocates virtual space for the bounds directory (malloc() essentially)
* points the hardware BNDCFGU register at the directory
* calls a new prctl() to notify the kernel to start managing the bounds directories
Kernel MPX Code:
* Checks for hardware MPX support in cpuid leaf
* Handles #BR exceptions and sends SIGSEGV to the app when it violates bounds, like during a buffer overflow.
* When bounds are spilled in to an unallocated bounds table, the kernel notices in the #BR exception, allocates the virtual space, then updates the bounds directory to point to the new table. It keeps special track of the memory with a specific ->vm_ops for MPX.
* Frees unused bounds tables at the time that the memory they described is unmapped. (See "cleanup unused bound tables")
=== Testing ==
This patchset has been tested on real internal hardware platform at Intel. We have some simple unit tests in user space, which directly call MPX instructions to produce #BR to let kernel allocate bounds tables and cause bounds violations. We also compiled several benchmarks with an MPX-enabled compiler and ran them with this patch set. We found a number of bugs in this code in these tests.
1. For more info on why the kernel does these allocations, see the patch "on-demand kernel allocation of bounds tables"
Future TODO items:
1) support 32-bit binaries on 64-bit kernels.
2) Remove dependence on mmap_sem for ->bd_addr serialization
3) Lots of performance work
4) Manpage (not a kernel patch, but worth mentioning) I have a patch to do it and will submit once this is merged.
5) prctl() so we can write wrappers to disable MPX in children
6) Tracepoints to help diagnose what's going on
Changes since v1:
* check to see if #BR occurred in userspace or kernel space.
* use generic structure and macro as much as possible when decode mpx instructions.
Changes since v2:
* fix some compile warnings.
* update documentation.
Changes since v3:
* correct some syntax errors at documentation, and document extended struct siginfo.
* for kill the process when the error code of BNDSTATUS is 3.
* add some comments.
* remove new prctl() commands.
* fix some compile warnings for 32-bit.
Changes since v4:
* raise SIGBUS if the allocations of the bound tables fail.
Changes since v5:
* hook unmap() path to cleanup unused bounds tables, and use new prctl() command to register bounds directory address to struct mm_struct to check whether one process is MPX enabled during unmap().
* in order track precisely MPX memory usage, add MPX specific mmap interface and one VM_MPX flag to check whether a VMA is MPX bounds table.
* add macro cpu_has_mpx to do performance optimization.
* sync struct figinfo for mips with general version to avoid build issue.
Changes since v6:
* because arch_vma_name is removed, this patchset have toset MPX
specific ->vm_ops to do the same thing.
* fix warnings for 32 bit arch.
* add more description into these patches.
Changes since v7:
* introduce VM_ARCH_2 flag.
* remove all of the pr_debug()s.
* fix prctl numbers in documentation.
* fix some bugs on bounds tables freeing.
Changes since v8:
* add new patch to rename cfg_reg_u and status_reg.
* add new patch to use disabled features from Dave's patches.
* add new patch to sync struct siginfo for IA64.
* rename two new prctl() commands to PR_MPX_ENABLE_MANAGEMENT and PR_MPX_DISABLE_MANAGEMENT, check whether the management of bounds tables in kernel is enabled at #BR fault time, and add locking to protect the access to 'bd_addr'.
* update the documentation file to add more content about on-demand allocation of bounds tables, etc..
Changes since v9:
* New instruction decoder. Uses generic infrastructure instead of "private" MPX decoder. (details in that patch)
* Switched over to using get_user_pages() to handle faults when we touch userspace.
* Lots of clarified comments and grammar fixups.
* Merged arch/x86/kernel/mpx.c and arch/x86/mm/mpx.c
* #ifdef'd the smaps display of the MPX flag (compile error on non-x86)
* Added code to use new functions to access the "xsaves" compact
PATCH v11 1/11 x86, mpx: rename cfg_reg_u and status_reg
From: Dave Hansen <[email protected]>
According to Intel SDM extension, MPX configuration and status registers should be BNDCFGU and BNDSTATUS. This patch renames cfg_reg_u and status_reg to bndcfgu and bndstatus.
---
b/arch/x86/include/asm/processor.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/include/asm/processor.h renamed from arch/x86/include/asm/processor.h~mpx-v11-rename-cfg-reg-u-and-status-reg +2 -2
@@ -380,8 +380,8 @@ struct bndreg { } __packed;struct bndcsr { -u64 cfg_reg_u; -u64 status_reg; +u64 bndcfgu; +u64 bndstatus; } __packed;struct xsave_hdr_struct {
_
tip-bot for Dave Hansen
merge bot[tip:x86/mpx] x86, mpx: Rename cfg_reg_u and status_reg
x86, mpx: Rename cfg_reg_u and status_reg
Commit-ID: 62e7759b1bdaf9b753c3724a56fcbe3235ebd5f3 Gitweb: http://git.kernel.org/tip/62e7759b1bdaf9b753c3724a56fcbe3235ebd5f3 Author: Dave Hansen <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:17 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
x86, mpx: Rename cfg_reg_u and status_reg
According to Intel SDM extension, MPX configuration and status registers should be BNDCFGU and BNDSTATUS. This patch renames cfg_reg_u and status_reg to bndcfgu and bndstatus.
[ tglx: Renamed 'struct bndscr_struct' to 'struct bndscr' ]
--- arch/x86/include/asm/processor.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
arch/x86/include/asm/processor.h +4 -4
@@ -379,9 +379,9 @@ struct bndreg {u64 upper_bound; } __packed; -struct bndcsr_struct { -u64 cfg_reg_u; -u64 status_reg; +struct bndcsr { +u64 bndcfgu; +u64 bndstatus; } __packed;struct xsave_hdr_struct {
@@ -396,7 +396,7 @@ struct xsave_struct {struct ymmh_struct ymmh;struct lwp_struct lwp;struct bndreg bndreg[4 ]; -struct bndcsr_struct bndcsr; +struct bndcsr bndcsr;/* new processor state extensions will go here */ } __attribute__ ((packed, aligned (64)));
PATCH v11 2/11 mpx: extend siginfo structure to include bound violation information
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
This patch adds new fields about bound violation into siginfo structure. si_lower and si_upper are respectively lower bound and upper bound when bound violation is caused.
---
b/include/uapi/asm-generic/siginfo.h | 9 ++++++++- b/kernel/signal.c | 4 ++++ 2 files changed, 12 insertions(+), 1 deletion(-)
include/uapi/asm-generic/siginfo.h renamed from include/uapi/asm-generic/siginfo.h~mpx-v11-mpx-extend-siginfo-structure-to-include-bound-violation-information +8 -1
@@ -91,6 +91,10 @@ typedef struct siginfo {int _trapno;/* TRAP # which caused the signal */ #endif short _addr_lsb;/* LSB of the reported address */ +struct { +void __user *_lower; +void __user *_upper; + } _addr_bnd; } _sigfault;/* SIGPOLL */
@@ -131,6 +135,8 @@ typedef struct siginfo {#define si_trapno _sifields._sigfault._trapno#endif #define si_addr_lsb _sifields._sigfault._addr_lsb +#define si_lower _sifields._sigfault._addr_bnd._lower +#define si_upper _sifields._sigfault._addr_bnd._upper#define si_band _sifields._sigpoll._band#define si_fd _sifields._sigpoll._fd#ifdef __ARCH_SIGSYS
@@ -199,7 +205,8 @@ typedef struct siginfo {*/ #define SEGV_MAPERR (__SI_FAULT|1)/* address not mapped to object */ #define SEGV_ACCERR (__SI_FAULT|2)/* invalid permissions for mapped object */ -#define NSIGSEGV 2 +#define SEGV_BNDERR (__SI_FAULT|3)/* failed address bound checks */ +#define NSIGSEGV 3/* * SIGBUS si_codes
kernel/signal.c renamed from kernel/signal.c~mpx-v11-mpx-extend-siginfo-structure-to-include-bound-violation-information +4 -0
@@ -2748,6 +2748,10 @@ int copy_siginfo_to_user(siginfo_t __useif (from->si_code =BUS_MCEERR_AR || from->si_code =BUS_MCEERR_AO ) err |=__put_user (from->si_addr_lsb, &to->si_addr_lsb);#endif +#ifdef SEGV_BNDERR + err |=__put_user (from->si_lower, &to->si_lower); + err |=__put_user (from->si_upper, &to->si_upper); +#endif break ;case __SI_CHLD: err |=__put_user (from->si_pid, &to->si_pid);
_
tip-bot for Qiaowei Ren
merge bot[tip:x86/mpx] mpx: Extend siginfo structure to include bound violation information
mpx: Extend siginfo structure to include bound violation information
Commit-ID: ee1b58d36aa1b5a79eaba11f5c3633c88231da83 Gitweb: http://git.kernel.org/tip/ee1b58d36aa1b5a79eaba11f5c3633c88231da83 Author: Qiaowei Ren <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:19 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
mpx: Extend siginfo structure to include bound violation information
This patch adds new fields about bound violation into siginfo structure. si_lower and si_upper are respectively lower bound and upper bound when bound violation is caused.
--- include/uapi/asm-generic/siginfo.h | 9 ++++++++- kernel/signal.c | 4 ++++ 2 files changed, 12 insertions(+), 1 deletion(-)
include/uapi/asm-generic/siginfo.h +8 -1
@@ -91,6 +91,10 @@ typedef struct siginfo {int _trapno;/* TRAP # which caused the signal */ #endif short _addr_lsb;/* LSB of the reported address */ +struct { +void __user *_lower; +void __user *_upper; + } _addr_bnd; } _sigfault;/* SIGPOLL */
@@ -131,6 +135,8 @@ typedef struct siginfo {#define si_trapno _sifields._sigfault._trapno#endif #define si_addr_lsb _sifields._sigfault._addr_lsb +#define si_lower _sifields._sigfault._addr_bnd._lower +#define si_upper _sifields._sigfault._addr_bnd._upper#define si_band _sifields._sigpoll._band#define si_fd _sifields._sigpoll._fd#ifdef __ARCH_SIGSYS
@@ -199,7 +205,8 @@ typedef struct siginfo {*/ #define SEGV_MAPERR (__SI_FAULT|1)/* address not mapped to object */ #define SEGV_ACCERR (__SI_FAULT|2)/* invalid permissions for mapped object */ -#define NSIGSEGV 2 +#define SEGV_BNDERR (__SI_FAULT|3)/* failed address bound checks */ +#define NSIGSEGV 3/* * SIGBUS si_codes
kernel/signal.c +4 -0
@@ -2748,6 +2748,10 @@ int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)if (from->si_code ==BUS_MCEERR_AR || from->si_code ==BUS_MCEERR_AO ) err |=__put_user (from->si_addr_lsb, &to->si_addr_lsb);#endif +#ifdef SEGV_BNDERR + err |=__put_user (from->si_lower, &to->si_lower); + err |=__put_user (from->si_upper, &to->si_upper); +#endif break ;case __SI_CHLD: err |=__put_user (from->si_pid, &to->si_pid);
PATCH v11 3/11 mips: sync struct siginfo with general version
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
New fields about bound violation are added into general struct siginfo. This will impact MIPS and IA64, which extend general struct siginfo. This patch syncs this struct for MIPS with general version.
---
b/arch/mips/include/uapi/asm/siginfo.h | 4 ++++ 1 file changed, 4 insertions(+)
arch/mips/include/uapi/asm/siginfo.h renamed from arch/mips/include/uapi/asm/siginfo.h~mpx-v11-mips-sync-struct-siginfo-with-general-version +4 -0
@@ -92,6 +92,10 @@ typedef struct siginfo {int _trapno;/* TRAP # which caused the signal */ #endif short _addr_lsb; +struct { +void __user *_lower; +void __user *_upper; + } _addr_bnd; } _sigfault;/* SIGPOLL, SIGXFSZ (To do ...) */
_
tip-bot for Qiaowei Ren
merge bot[tip:x86/mpx] mips: Sync struct siginfo with general version
mips: Sync struct siginfo with general version
Commit-ID: 232b5fff5bad78ad00b94153fa90ca53bef6a444 Gitweb: http://git.kernel.org/tip/232b5fff5bad78ad00b94153fa90ca53bef6a444 Author: Qiaowei Ren <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:20 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
mips: Sync struct siginfo with general version
New fields about bound violation are added into general struct siginfo. This will impact MIPS and IA64, which extend general struct siginfo. This patch syncs this struct for MIPS with general version.
--- arch/mips/include/uapi/asm/siginfo.h | 4 ++++ 1 file changed, 4 insertions(+)
arch/mips/include/uapi/asm/siginfo.h +4 -0
@@ -92,6 +92,10 @@ typedef struct siginfo {int _trapno;/* TRAP # which caused the signal */ #endif short _addr_lsb; +struct { +void __user *_lower; +void __user *_upper; + } _addr_bnd; } _sigfault;/* SIGPOLL, SIGXFSZ (To do ...) */
PATCH v11 4/11 ia64: sync struct siginfo with general version
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
New fields about bound violation are added into general struct siginfo. This will impact MIPS and IA64, which extend general struct siginfo. This patch syncs this struct for IA64 with general version.
---
b/arch/ia64/include/uapi/asm/siginfo.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
arch/ia64/include/uapi/asm/siginfo.h renamed from arch/ia64/include/uapi/asm/siginfo.h~mpx-v11-ia64-sync-struct-siginfo-with-general-version +6 -2
@@ -63,6 +63,10 @@ typedef struct siginfo {unsigned int _flags;/* see below */ unsigned long _isr;/* isr */ short _addr_lsb;/* lsb of faulting address */ +struct { +void __user *_lower; +void __user *_upper; + } _addr_bnd; } _sigfault;/* SIGPOLL */
@@ -110,9 +114,9 @@ typedef struct siginfo {/* * SIGSEGV si_codes */ -#define __SEGV_PSTKOVF (__SI_FAULT|3)/* paragraph stack overflow */ +#define __SEGV_PSTKOVF (__SI_FAULT|4)/* paragraph stack overflow */ #undef NSIGSEGV -#define NSIGSEGV 3 +#define NSIGSEGV 4#undef NSIGTRAP#define NSIGTRAP 4
_
tip-bot for Qiaowei Ren
merge bot[tip:x86/mpx] ia64: Sync struct siginfo with general version
ia64: Sync struct siginfo with general version
Commit-ID: 53f037b08b5bebf47aa2b574a984e2f9fc7926f2 Gitweb: http://git.kernel.org/tip/53f037b08b5bebf47aa2b574a984e2f9fc7926f2 Author: Qiaowei Ren <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:22 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
ia64: Sync struct siginfo with general version
New fields about bound violation are added into general struct siginfo. This will impact MIPS and IA64, which extend general struct siginfo. This patch syncs this struct for IA64 with general version.
--- arch/ia64/include/uapi/asm/siginfo.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
arch/ia64/include/uapi/asm/siginfo.h +6 -2
@@ -63,6 +63,10 @@ typedef struct siginfo {unsigned int _flags;/* see below */ unsigned long _isr;/* isr */ short _addr_lsb;/* lsb of faulting address */ +struct { +void __user *_lower; +void __user *_upper; + } _addr_bnd; } _sigfault;/* SIGPOLL */
@@ -110,9 +114,9 @@ typedef struct siginfo {/* * SIGSEGV si_codes */ -#define __SEGV_PSTKOVF (__SI_FAULT|3)/* paragraph stack overflow */ +#define __SEGV_PSTKOVF (__SI_FAULT|4)/* paragraph stack overflow */ #undef NSIGSEGV -#define NSIGSEGV 3 +#define NSIGSEGV 4#undef NSIGTRAP#define NSIGTRAP 4
PATCH v11 5/11 x86, mpx: add MPX to disaabled features
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
This allows us to use cpu_feature_enabled(X86_FEATURE_MPX) as both a runtime and compile-time check.
When CONFIG_X86_INTEL_MPX is disabled, cpu_feature_enabled(X86_FEATURE_MPX) will evaluate at compile-time to 0. If CONFIG_X86_INTEL_MPX=y, then the cpuid flag will be checked at runtime.
---
b/arch/x86/include/asm/disabled-features.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/x86/include/asm/disabled-features.h renamed from arch/x86/include/asm/disabled-features.h~mpx-v11-add-MPX-to-disaabled-features +7 -1
@@ -10,6 +10,12 @@* cpu_feature_enabled(). */ +#ifdef CONFIG_X86_INTEL_MPX +# define DISABLE_MPX 0 +#else +# define DISABLE_MPX (1<<(X86_FEATURE_MPX & 31)) +#endif +#ifdef CONFIG_X86_64 # define DISABLE_VME (1<<(X86_FEATURE_VME & 31))# define DISABLE_K6_MTRR (1<<(X86_FEATURE_K6_MTRR & 31))
@@ -34,6 +40,6 @@#define DISABLED_MASK6 0#define DISABLED_MASK7 0#define DISABLED_MASK8 0 -#define DISABLED_MASK9 0 +#define DISABLED_MASK9 (DISABLE_MPX)#endif /* _ASM_X86_DISABLED_FEATURES_H */
_
Re: [PATCH 05/11] x86, mpx: add MPX to disaabled features
Hello.
Quoted 20 lines · Dave Hansen
From: Dave Hansen <[email protected]>
This allows us to use
cpu_feature_enabled(X86_FEATURE_MPX)as both a runtime and compile-time check.When
CONFIG_X86_INTEL_MPXis disabled,cpu_feature_enabled(X86_FEATURE_MPX)will evaluate at compile-time to 0. IfCONFIG_X86_INTEL_MPX=y, then the cpuid flag will be checked at runtime.Signed-off-by Dave Hansen <[email protected]>Signed-off-by Qiaowei Ren <[email protected]>---
b/arch/x86/include/asm/disabled-features.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)diff -puN
arch/x86/include/asm/disabled-features.h~mpx-v11-add-MPX-to-disaabled-featuresarch/x86/include/asm/disabled-features.harch/x86/include/asm/disabled-features.h renamed from arch/x86/include/asm/disabled-features.h~mpx-v11-add-MPX-to-disaabled-features +0
-0
[...]
arch/x86/include/asm/disabled-features.h line 43
Quoted 6 lines
arch/x86/include/asm/disabled-features.h renamed from arch/x86/include/asm/disabled-features.h~mpx-v11-add-MPX-to-disaabled-features +1
-1@@ -34,6 +40,6 @@#define DISABLED_MASK6 0#define DISABLED_MASK7 0#define DISABLED_MASK8 0 -#define DISABLED_MASK9 0 +#define DISABLED_MASK9 (DISABLE_MPX)
These parens are not really needed. Sorry to be a PITA and not saying this
before.
[...]
WBR, Sergei
Re: [PATCH 05/11] x86, mpx: add MPX to disaabled features
Quoted 8 lines · Sergei Shtylyov
arch/x86/include/asm/disabled-features.h line 43
Quoted 5 lines
#define DISABLED_MASK6 0 #define DISABLED_MASK7 0 #define DISABLED_MASK8 0arch/x86/include/asm/disabled-features.h renamed from arch/x86/include/asm/disabled-features.h~mpx-v11-add-MPX-to-disaabled-features +1
-1-#define DISABLED_MASK9 0 +#define DISABLED_MASK9 (DISABLE_MPX)These parens are not really needed. Sorry to be a PITA and not saying
this before.
One goal of the disabled features patch was to maintain parity with required-features.h. It declares things this way:
Quoted 2 lines
#define
REQUIRED_MASK3(NEED_NOPL)
#defineREQUIRED_MASK4(NEED_MOVBE)
So, no, those aren't strictly needed, but there is precedent for them and they do no harm. I think I'll leave them as-is.
tip-bot for Dave Hansen
merge bot[tip:x86/mpx] x86, mpx: Add MPX to disabled features
In reply to Dave Hansenx86, mpx: Add MPX to disabled features
Commit-ID: 95290cf13e561b52dceadb9a8b8ee8ff2464b142 Gitweb: http://git.kernel.org/tip/95290cf13e561b52dceadb9a8b8ee8ff2464b142 Author: Dave Hansen <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:23 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
x86, mpx: Add MPX to disabled features
This allows us to use cpu_feature_enabled(X86_FEATURE_MPX) as both a runtime and compile-time check.
When CONFIG_X86_INTEL_MPX is disabled, cpu_feature_enabled(X86_FEATURE_MPX) will evaluate at compile-time to 0. If CONFIG_X86_INTEL_MPX=y, then the cpuid flag will be checked at runtime.
--- arch/x86/include/asm/disabled-features.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
arch/x86/include/asm/disabled-features.h +7 -1
@@ -10,6 +10,12 @@* cpu_feature_enabled(). */ +#ifdef CONFIG_X86_INTEL_MPX +# define DISABLE_MPX 0 +#else +# define DISABLE_MPX (1<<(X86_FEATURE_MPX & 31)) +#endif +#ifdef CONFIG_X86_64 # define DISABLE_VME (1<<(X86_FEATURE_VME & 31))# define DISABLE_K6_MTRR (1<<(X86_FEATURE_K6_MTRR & 31))
@@ -34,6 +40,6 @@#define DISABLED_MASK6 0#define DISABLED_MASK7 0#define DISABLED_MASK8 0 -#define DISABLED_MASK9 0 +#define DISABLED_MASK9 (DISABLE_MPX)#endif /* _ASM_X86_DISABLED_FEATURES_H */
PATCH v11 6/11 x86, mpx: introduce VM_MPX to indicate that a VMA is MPX specific
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
MPX-enabled applications using large swaths of memory can potentially have large numbers of bounds tables in process address space to save bounds information. These tables can take up huge swaths of memory (as much as 80% of the memory on the system) even if we clean them up aggressively. In the worst-case scenario, the tables can be 4x the size of the data structure being tracked. IOW, a 1-page structure can require 4 bounds-table pages.
Being this huge, our expectation is that folks using MPX are going to be keen on figuring out how much memory is being dedicated to it. So we need a way to track memory use for MPX.
If we want to specifically track MPX VMAs we need to be able to distinguish them from normal VMAs, and keep them from getting merged with normal VMAs. A new VM_ flag set only on MPX VMAs does both of those things. With this flag, MPX bounds-table VMAs can be distinguished from other VMAs, and userspace can also walk /proc/$pid/smaps to get memory usage for MPX.
In addition to this flag, we also introduce a special ->vm_ops specific to MPX VMAs (see the patch "add MPX specific mmap interface"), but currently different ->vm_ops do not by themselves prevent VMA merging, so we still need this flag.
We understand that VM_ flags are scarce and are open to other options.
---
b/fs/proc/task_mmu.c | 3 +++ b/include/linux/mm.h | 6 ++++++ 2 files changed, 9 insertions(+)
fs/proc/task_mmu.c renamed from fs/proc/task_mmu.c~mpx-v11-introduce-VM-MPX-to-indicate-that-a-VMA-is-MPX-specific +3 -0
@@ -552,6 +552,9 @@ static void show_smap_vma_flags(struct s [ilog2(VM_GROWSDOWN)] = "gd", [ilog2(VM_PFNMAP)] = "pf", [ilog2(VM_DENYWRITE)] = "dw", +#ifdef CONFIG_X86_INTEL_MPX + [ilog2(VM_MPX)] = "mp", +#endif [ilog2(VM_LOCKED)] = "lo", [ilog2(VM_IO)] = "io", [ilog2(VM_SEQ_READ)] = "sr",
include/linux/mm.h renamed from include/linux/mm.h~mpx-v11-introduce-VM-MPX-to-indicate-that-a-VMA-is-MPX-specific +6 -0
@@ -128,6 +128,7 @@ extern unsigned int kobjsize(const void#define VM_HUGETLB 0x00400000/* Huge TLB Page VM */ #define VM_NONLINEAR 0x00800000/* Is non-linear (remap_file_pages) */ #define VM_ARCH_1 0x01000000/* Architecture-specific flag */ +#define VM_ARCH_2 0x02000000#define VM_DONTDUMP 0x04000000/* Do not include in the core dump */ #ifdef CONFIG_MEM_SOFT_DIRTY
@@ -155,6 +156,11 @@ extern unsigned int kobjsize(const void# define VM_MAPPED_COPY VM_ARCH_1/* T if mapped copy of data (nommu mmap) */ #endif +#if defined(CONFIG_X86 ) +/* MPX specific bounds table or bounds directory */ +# define VM_MPX VM_ARCH_2 +#endif +#ifndef VM_GROWSUP # define VM_GROWSUP VM_NONE#endif
_
tip-bot for Qiaowei Ren
merge bot[tip:x86/mpx] x86, mpx: Introduce VM_MPX to indicate that a VMA is MPX specific
x86, mpx: Introduce VM_MPX to indicate that a VMA is MPX specific
Commit-ID: 4aae7e436fa51faf4bf5d11b175aea82cfe8224a Gitweb: http://git.kernel.org/tip/4aae7e436fa51faf4bf5d11b175aea82cfe8224a Author: Qiaowei Ren <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:25 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
x86, mpx: Introduce VM_MPX to indicate that a VMA is MPX specific
MPX-enabled applications using large swaths of memory can potentially have large numbers of bounds tables in process address space to save bounds information. These tables can take up huge swaths of memory (as much as 80% of the memory on the system) even if we clean them up aggressively. In the worst-case scenario, the tables can be 4x the size of the data structure being tracked. IOW, a 1-page structure can require 4 bounds-table pages.
Being this huge, our expectation is that folks using MPX are going to be keen on figuring out how much memory is being dedicated to it. So we need a way to track memory use for MPX.
If we want to specifically track MPX VMAs we need to be able to distinguish them from normal VMAs, and keep them from getting merged with normal VMAs. A new VM_ flag set only on MPX VMAs does both of those things. With this flag, MPX bounds-table VMAs can be distinguished from other VMAs, and userspace can also walk /proc/$pid/smaps to get memory usage for MPX.
In addition to this flag, we also introduce a special ->vm_ops specific to MPX VMAs (see the patch "add MPX specific mmap interface"), but currently different ->vm_ops do not by themselves prevent VMA merging, so we still need this flag.
We understand that VM_ flags are scarce and are open to other options.
--- fs/proc/task_mmu.c | 3 +++ include/linux/mm.h | 6 ++++++ 2 files changed, 9 insertions(+)
fs/proc/task_mmu.c +3 -0
@@ -552,6 +552,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) [ilog2(VM_GROWSDOWN)] = "gd", [ilog2(VM_PFNMAP)] = "pf", [ilog2(VM_DENYWRITE)] = "dw", +#ifdef CONFIG_X86_INTEL_MPX + [ilog2(VM_MPX)] = "mp", +#endif [ilog2(VM_LOCKED)] = "lo", [ilog2(VM_IO)] = "io", [ilog2(VM_SEQ_READ)] = "sr",
include/linux/mm.h +6 -0
@@ -128,6 +128,7 @@ extern unsigned int kobjsize(const void *objp);#define VM_HUGETLB 0x00400000/* Huge TLB Page VM */ #define VM_NONLINEAR 0x00800000/* Is non-linear (remap_file_pages) */ #define VM_ARCH_1 0x01000000/* Architecture-specific flag */ +#define VM_ARCH_2 0x02000000#define VM_DONTDUMP 0x04000000/* Do not include in the core dump */ #ifdef CONFIG_MEM_SOFT_DIRTY
@@ -155,6 +156,11 @@ extern unsigned int kobjsize(const void *objp);# define VM_MAPPED_COPY VM_ARCH_1/* T if mapped copy of data (nommu mmap) */ #endif +#if defined(CONFIG_X86 ) +/* MPX specific bounds table or bounds directory */ +# define VM_MPX VM_ARCH_2 +#endif +#ifndef VM_GROWSUP # define VM_GROWSUP VM_NONE#endif
PATCH v11 7/11 x86, mpx: add MPX-specific mmap interface
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
We have chosen to perform the allocation of bounds tables in kernel (See the patch "on-demand kernel allocation of bounds tables") and to mark these VMAs with VM_MPX.
However, there is currently no suitable interface to actually do this. Existing interfaces, like do_mmap_pgoff(), have no way to set a modified ->vm_ops or ->vm_flags and don't hold mmap_sem long enough to let a caller do it.
This patch wraps mmap_region() and hold mmap_sem long enough to make the modifications to the VMA which we need.
Also note the 32/64-bit #ifdef in the header. We actually need to do this at runtime eventually. But, for now, we don't support running 32-bit binaries on 64-bit kernels. Support for this will come in later patches.
---
b/arch/x86/Kconfig | 4 ++ b/arch/x86/include/asm/mpx.h | 36 ++++++++++++++++++ b/arch/x86/mm/Makefile | 2 + b/arch/x86/mm/mpx.c | 86 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 128 insertions(+)
arch/x86/include/asm/mpx.h new file +36 -0
@@ -0,0 +1,36 @@ +#ifndef _ASM_X86_MPX_H +#define _ASM_X86_MPX_H + +#include <linux/types.h> +#include <asm/ptrace.h> + +#ifdef CONFIG_X86_64 + +/* upper 28 bits [47:20] of the virtual address in 64-bit used to +* index into bounds directory (BD). +*/ +#define MPX_BD_ENTRY_OFFSET 28 +#define MPX_BD_ENTRY_SHIFT 3 +/* bits [19:3] of the virtual address in 64-bit used to index into +* bounds table (BT). +*/ +#define MPX_BT_ENTRY_OFFSET 17 +#define MPX_BT_ENTRY_SHIFT 5 +#define MPX_IGN_BITS 3 + +#else + +#define MPX_BD_ENTRY_OFFSET 20 +#define MPX_BD_ENTRY_SHIFT 2 +#define MPX_BT_ENTRY_OFFSET 10 +#define MPX_BT_ENTRY_SHIFT 4 +#define MPX_IGN_BITS 2 + +#endif + +#define MPX_BD_SIZE_BYTES (1UL<<(MPX_BD_ENTRY_OFFSET+MPX_BD_ENTRY_SHIFT)) +#define MPX_BT_SIZE_BYTES (1UL<<(MPX_BT_ENTRY_OFFSET+MPX_BT_ENTRY_SHIFT)) + +#define MPX_BNDSTA_ERROR_CODE 0x3 + +#endif /* _ASM_X86_MPX_H */
arch/x86/Kconfig renamed from arch/x86/Kconfig~mpx-v11-add-MPX-specific-mmap-interface +4 -0
@@ -244,6 +244,10 @@ config HAVE_INTEL_TXT def_bool y depends on INTEL_IOMMU && ACPI +config X86_INTEL_MPX + def_bool y + depends on CPU_SUP_INTEL + config X86_32_SMP def_bool y depends on X86_32 && SMP
arch/x86/mm/Makefile renamed from arch/x86/mm/Makefile~mpx-v11-add-MPX-specific-mmap-interface +2 -0
@@ -30,3 +30,5 @@ obj-$(CONFIG_ACPI_NUMA) += srat.o obj-$(CONFIG_NUMA_EMU) += numa_emulation.o obj-$(CONFIG_MEMTEST) += memtest.o + +obj-$(CONFIG_X86_INTEL_MPX) += mpx.o
arch/x86/mm/mpx.c new file +86 -0
86 lines not on this page · raw message
_
tip-bot for Qiaowei Ren
merge bot[tip:x86/mpx] x86, mpx: Add MPX-specific mmap interface
x86, mpx: Add MPX-specific mmap interface
Commit-ID: 57319d80e1d328e34cb24868a4f4405661485e30 Gitweb: http://git.kernel.org/tip/57319d80e1d328e34cb24868a4f4405661485e30 Author: Qiaowei Ren <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:27 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
x86, mpx: Add MPX-specific mmap interface
We have chosen to perform the allocation of bounds tables in kernel (See the patch "on-demand kernel allocation of bounds tables") and to mark these VMAs with VM_MPX.
However, there is currently no suitable interface to actually do this. Existing interfaces, like do_mmap_pgoff(), have no way to set a modified ->vm_ops or ->vm_flags and don't hold mmap_sem long enough to let a caller do it.
This patch wraps mmap_region() and hold mmap_sem long enough to make the modifications to the VMA which we need.
Also note the 32/64-bit #ifdef in the header. We actually need to do this at runtime eventually. But, for now, we don't support running 32-bit binaries on 64-bit kernels. Support for this will come in later patches.
--- arch/x86/Kconfig | 4 +++ arch/x86/include/asm/mpx.h | 36 +++++++++++++++++++ arch/x86/mm/Makefile | 2 ++ arch/x86/mm/mpx.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 128 insertions(+)
arch/x86/Kconfig +4 -0
@@ -248,6 +248,10 @@ config HAVE_INTEL_TXT def_bool y depends on INTEL_IOMMU && ACPI +config X86_INTEL_MPX + def_bool y + depends on CPU_SUP_INTEL + config X86_32_SMP def_bool y depends on X86_32 && SMP
arch/x86/include/asm/mpx.h new file +36 -0
@@ -0,0 +1,36 @@ +#ifndef _ASM_X86_MPX_H +#define _ASM_X86_MPX_H + +#include <linux/types.h> +#include <asm/ptrace.h> + +#ifdef CONFIG_X86_64 + +/* upper 28 bits [47:20] of the virtual address in 64-bit used to +* index into bounds directory (BD). +*/ +#define MPX_BD_ENTRY_OFFSET 28 +#define MPX_BD_ENTRY_SHIFT 3 +/* bits [19:3] of the virtual address in 64-bit used to index into +* bounds table (BT). +*/ +#define MPX_BT_ENTRY_OFFSET 17 +#define MPX_BT_ENTRY_SHIFT 5 +#define MPX_IGN_BITS 3 + +#else + +#define MPX_BD_ENTRY_OFFSET 20 +#define MPX_BD_ENTRY_SHIFT 2 +#define MPX_BT_ENTRY_OFFSET 10 +#define MPX_BT_ENTRY_SHIFT 4 +#define MPX_IGN_BITS 2 + +#endif + +#define MPX_BD_SIZE_BYTES (1UL<<(MPX_BD_ENTRY_OFFSET+MPX_BD_ENTRY_SHIFT)) +#define MPX_BT_SIZE_BYTES (1UL<<(MPX_BT_ENTRY_OFFSET+MPX_BT_ENTRY_SHIFT)) + +#define MPX_BNDSTA_ERROR_CODE 0x3 + +#endif /* _ASM_X86_MPX_H */
arch/x86/mm/Makefile +2 -0
@@ -30,3 +30,5 @@ obj-$(CONFIG_ACPI_NUMA) += srat.o obj-$(CONFIG_NUMA_EMU) += numa_emulation.o obj-$(CONFIG_MEMTEST) += memtest.o + +obj-$(CONFIG_X86_INTEL_MPX) += mpx.o
arch/x86/mm/mpx.c new file +86 -0
86 lines not on this page · raw message
PATCH v11 8/11 x86, mpx: [new code] decode MPX instruction to get bound violation information
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
Note: This is substantially different code from the v9 set.
This patch sets bound violation fields of siginfo struct in #BR exception handler by decoding the user instruction and constructing the faulting pointer.
We have to be very careful when decoding these instructions. They are completely controlled by userspace and may be changed at any time up to and including the point where we try to copy them in to the kernel. They may or may not be MPX instructions and could be completely invalid for all we know.
Note: This code is based on Qiaowei Ren's specialized MPX decoder, but uses the generic decoder whenever possible. It was tested for robustness by generating a completely random data stream and trying to decode that stream. I also unmapped random pages inside the stream to test the "partial instruction" short read code.
We kzalloc() the siginfo instead of stack allocating it because we need to memset() it anyway, and doing this makes it much more clear when it got initialized by the MPX instruction decoder.
Changes from the old decoder:
* Use the generic decoder instead of custom functions. Saved ~70 lines of code overall.
* Remove insn->addr_bytes code (never used??)
* Make sure never to possibly overflow the regoff[] array, plus check the register range correctly in 32 and 64-bit modes.
* Allow get_reg() to return an error and have mpx_get_addr_ref() handle when it sees errors.
* Only call insn_get_*() near where we actually use the values instead if trying to call them all at once.
* Handle short reads from copy_from_user() and check the actual number of read bytes against what we expect from insn_get_length(). If a read stops in the middle of an instruction, we error out.
* Actually check the opcodes intead of ignoring them.
* Dynamically kzalloc() siginfo_t so we don't leak any stack data.
* Detect and handle decoder failures instead of ignoring them.
---
b/arch/x86/include/asm/mpx.h | 12 ++ b/arch/x86/mm/mpx.c | 237 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 249 insertions(+)
arch/x86/include/asm/mpx.h renamed from arch/x86/include/asm/mpx.h~mpx-v11-new-decoder +12 -0
@@ -3,6 +3,7 @@#include <linux/types.h> #include <asm/ptrace.h> +#include <asm/insn.h> #ifdef CONFIG_X86_64
@@ -33,4 +34,15 @@#define MPX_BNDSTA_ERROR_CODE 0x3 +#ifdef CONFIG_X86_INTEL_MPX +siginfo_t *mpx_generate_siginfo (struct pt_regs *regs, +struct xsave_struct *xsave_buf); +#else +static inline siginfo_t *mpx_generate_siginfo (struct pt_regs *regs, +struct xsave_struct *xsave_buf) +{ +return NULL ; +} +#endif /* CONFIG_X86_INTEL_MPX */ +#endif /* _ASM_X86_MPX_H */
arch/x86/mm/mpx.c renamed from arch/x86/mm/mpx.c~mpx-v11-new-decoder +237 -0
246 lines not on this page · raw message
_
tip-bot for Dave Hansen
merge bot[tip:x86/mpx] x86, mpx: Decode MPX instruction to get bound violation information
x86, mpx: Decode MPX instruction to get bound violation information
Commit-ID: fcc7ffd67991b63029ca54925644753d534ddc5f Gitweb: http://git.kernel.org/tip/fcc7ffd67991b63029ca54925644753d534ddc5f Author: Dave Hansen <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:28 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
x86, mpx: Decode MPX instruction to get bound violation information
This patch sets bound violation fields of siginfo struct in #BR exception handler by decoding the user instruction and constructing the faulting pointer.
We have to be very careful when decoding these instructions. They are completely controlled by userspace and may be changed at any time up to and including the point where we try to copy them in to the kernel. They may or may not be MPX instructions and could be completely invalid for all we know.
Note: This code is based on Qiaowei Ren's specialized MPX decoder, but uses the generic decoder whenever possible. It was tested for robustness by generating a completely random data stream and trying to decode that stream. I also unmapped random pages inside the stream to test the "partial instruction" short read code.
We kzalloc() the siginfo instead of stack allocating it because we need to memset() it anyway, and doing this makes it much more clear when it got initialized by the MPX instruction decoder.
Changes from the old decoder:
* Use the generic decoder instead of custom functions. Saved ~70 lines of code overall.
* Remove insn->addr_bytes code (never used??)
* Make sure never to possibly overflow the regoff[] array, plus check the register range correctly in 32 and 64-bit modes.
* Allow get_reg() to return an error and have mpx_get_addr_ref() handle when it sees errors.
* Only call insn_get_*() near where we actually use the values instead if trying to call them all at once.
* Handle short reads from copy_from_user() and check the actual number of read bytes against what we expect from insn_get_length(). If a read stops in the middle of an instruction, we error out.
* Actually check the opcodes intead of ignoring them.
* Dynamically kzalloc() siginfo_t so we don't leak any stack data.
* Detect and handle decoder failures instead of ignoring them.
--- arch/x86/include/asm/mpx.h | 12 +++ arch/x86/mm/mpx.c | 237 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 249 insertions(+)
arch/x86/include/asm/mpx.h +12 -0
@@ -3,6 +3,7 @@#include <linux/types.h> #include <asm/ptrace.h> +#include <asm/insn.h> #ifdef CONFIG_X86_64
@@ -33,4 +34,15 @@#define MPX_BNDSTA_ERROR_CODE 0x3 +#ifdef CONFIG_X86_INTEL_MPX +siginfo_t *mpx_generate_siginfo (struct pt_regs *regs, +struct xsave_struct *xsave_buf); +#else +static inline siginfo_t *mpx_generate_siginfo (struct pt_regs *regs, +struct xsave_struct *xsave_buf) +{ +return NULL ; +} +#endif /* CONFIG_X86_INTEL_MPX */ +#endif /* _ASM_X86_MPX_H */
arch/x86/mm/mpx.c +237 -0
246 lines not on this page · raw message
PATCH v11 9/11 x86, mpx: on-demand kernel allocation of bounds tables
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
changes from v10:
* move mm init-time #ifdef to mpx.h
* add comment in do_bounds() about why xsave is needed
* add missing return in do_bounds();
* unconvolute mpx_handle_bd_fault()
--
This is really the meat of the MPX patch set. If there is one patch to review in the entire series, this is the one. There is a new ABI here and this kernel code also interacts with userspace memory in a relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the management of bounds tables in kernel, including on-demand kernel allocation (See the patch "on-demand kernel allocation of bounds tables") and cleanup (See the patch "cleanup unused bound tables"). Applications do not strictly need the kernel to manage bounds tables and we expect some applications to use MPX without taking advantage of this kernel support. This means the kernel can not simply infer whether an application needs bounds table management from the MPX registers. The prctl() is an explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds directory out of a userspace register (bndcfgu) and then cache it into a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT will set "bd_addr" to an invalid address. Using this scheme, we can use "bd_addr" to determine whether the management of bounds tables in kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves, which can be expensive. Caching "bd_addr" like this also helps reduce the cost of those xsaves when doing table cleanup at munmap() time. Unfortunately, we can not apply this optimization to #BR fault time because we need an xsave to get the value of BNDSTATUS.
== Why does the hardware even have these Bounds Tables? ==
MPX only has 4 hardware registers for storing bounds information. If MPX-enabled code needs more than these 4 registers, it needs to spill them somewhere. It has two special instructions for this which allow the bounds to be moved between the bounds registers and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by the MPX hardware during both bounds violations or when the tables are not present. This patch handles those #BR exceptions for not-present tables by carving the space out of the normal processes address space (essentially calling the new mmap() interface indroduced earlier in this patch set.) and then pointing the bounds-directory over to it.
The tables *need* to be accessed and controlled by userspace because the instructions for moving bounds in and out of them are extremely frequent. They potentially happen every time a register pointing to memory is dereferenced. Any direct kernel involvement (like a syscall) to access the tables would obviously destroy performance.
== Why not do this in userspace? ==
This patch is obviously doing this allocation in the kernel. However, MPX does not strictly *require* anything in the kernel. It can theoretically be done completely from userspace. Here are a few ways this *could* be done. I don't think any of them are practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds directory. If we were to preallocate them for the 128TB of user virtual address space, we would need to reserve 512TB+2GB, which is larger than the entire virtual address space today. This means they can not be reserved ahead of time. Also, a single process's pre-popualated bounds directory consumes 2GB of virtual *AND* physical memory. IOW, it's completely infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small, constrained applications. But, it isn't practical at a larger scale since a given app has no way of controlling how all the parts of the app might allocate memory (think libraries). The kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still requires locking or nasty tricks to keep track of the allocation state there.
Having ruled out all of the userspace-only approaches for managing bounds tables that we could think of, we create them on demand in the kernel.
---
b/arch/x86/include/asm/mmu_context.h | 10 + b/arch/x86/include/asm/mpx.h | 37 +++++ b/arch/x86/include/asm/processor.h | 18 ++ b/arch/x86/kernel/mpx.c | 1 b/arch/x86/kernel/setup.c | 7 + b/arch/x86/kernel/traps.c | 85 +++++++++++++ b/arch/x86/mm/mpx.c | 225 ++++++++++++++++++++++++++++++++++- b/fs/exec.c | 2 b/include/asm-generic/mmu_context.h | 5 b/include/linux/mm_types.h | 3 b/include/uapi/linux/prctl.h | 6 b/kernel/sys.c | 12 + 12 files changed, 405 insertions(+), 6 deletions(-)
arch/x86/include/asm/mmu_context.h renamed from arch/x86/include/asm/mmu_context.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +10 -0
@@ -10,6 +10,7 @@#include <asm/pgalloc.h> #include <asm/tlbflush.h> #include <asm/paravirt.h> +#include <asm/mpx.h> #ifndef CONFIG_PARAVIRT #include <asm-generic/mm_hooks.h>
@@ -102,4 +103,13 @@ do { \ } while (0)#endif +static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +mpx_mm_init (mm); +#ifdef CONFIG_X86_INTEL_MPX + mm->bd_addr =MPX_INVALID_BOUNDS_DIR ; +#endif +} +#endif /* _ASM_X86_MMU_CONTEXT_H */
arch/x86/include/asm/mpx.h renamed from arch/x86/include/asm/mpx.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +37 -0
@@ -5,6 +5,14 @@#include <asm/ptrace.h> #include <asm/insn.h> +/* +* NULL is theoretically a valid place to put the bounds +* directory, so point this at an invalid address. +*/ +#define MPX_INVALID_BOUNDS_DIR ((void __user *)-1) +#define MPX_BNDCFG_ENABLE_FLAG 0x1 +#define MPX_BD_ENTRY_VALID_FLAG 0x1 +#ifdef CONFIG_X86_64 /* upper 28 bits [47:20] of the virtual address in 64-bit used to
@@ -18,6 +26,7 @@#define MPX_BT_ENTRY_OFFSET 17#define MPX_BT_ENTRY_SHIFT 5#define MPX_IGN_BITS 3 +#define MPX_BD_ENTRY_TAIL 3#else
@@ -26,23 +35,51 @@#define MPX_BT_ENTRY_OFFSET 10#define MPX_BT_ENTRY_SHIFT 4#define MPX_IGN_BITS 2 +#define MPX_BD_ENTRY_TAIL 2#endif #define MPX_BD_SIZE_BYTES (1UL<<(MPX_BD_ENTRY_OFFSET+MPX_BD_ENTRY_SHIFT))#define MPX_BT_SIZE_BYTES (1UL<<(MPX_BT_ENTRY_OFFSET+MPX_BT_ENTRY_SHIFT)) +#define MPX_BNDSTA_TAIL 2 +#define MPX_BNDCFG_TAIL 12 +#define MPX_BNDSTA_ADDR_MASK (~((1UL<<MPX_BNDSTA_TAIL)-1)) +#define MPX_BNDCFG_ADDR_MASK (~((1UL<<MPX_BNDCFG_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#ifdef CONFIG_X86_INTEL_MPX siginfo_t *mpx_generate_siginfo (struct pt_regs *regs,struct xsave_struct *xsave_buf); +int mpx_handle_bd_fault (struct xsave_struct *xsave_buf); +static inline int kernel_managing_mpx_tables (struct mm_struct *mm) +{ +return (mm->bd_addr !=MPX_INVALID_BOUNDS_DIR ); +} +static inline void mpx_mm_init (struct mm_struct *mm) +{ + mm->bd_addr =MPX_INVALID_BOUNDS_DIR ; +}#else static inline siginfo_t *mpx_generate_siginfo (struct pt_regs *regs,struct xsave_struct *xsave_buf) {return NULL ; } +static inline int mpx_handle_bd_fault (struct xsave_struct *xsave_buf) +{ +return -EINVAL ; +} +static inline int kernel_managing_mpx_tables (struct mm_struct *mm) +{ +return 0 ; +} +static inline void mpx_mm_init (struct mm_struct *mm) +{ +}#endif /* CONFIG_X86_INTEL_MPX */ #endif /* _ASM_X86_MPX_H */
arch/x86/include/asm/processor.h renamed from arch/x86/include/asm/processor.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +18 -0
@@ -954,6 +954,24 @@ extern void start_thread(struct pt_regsextern int get_tsc_mode (unsigned long adr);extern int set_tsc_mode (unsigned int val); +/* Register/unregister a process' MPX related resource */ +#define MPX_ENABLE_MANAGEMENT (tsk) mpx_enable_management((tsk)) +#define MPX_DISABLE_MANAGEMENT (tsk) mpx_disable_management((tsk)) + +#ifdef CONFIG_X86_INTEL_MPX +extern int mpx_enable_management (struct task_struct *tsk); +extern int mpx_disable_management (struct task_struct *tsk); +#else +static inline int mpx_enable_management (struct task_struct *tsk) +{ +return -EINVAL ; +} +static inline int mpx_disable_management (struct task_struct *tsk) +{ +return -EINVAL ; +} +#endif /* CONFIG_X86_INTEL_MPX */ +extern u16 amd_get_nb_id (int cpu);static inline uint32_t hypervisor_cpuid_base (const char *sig,uint32_t leaves)
arch/x86/kernel/mpx.c new file +1 -0
@@ -0,0 +1 @@ +
arch/x86/kernel/setup.c renamed from arch/x86/kernel/setup.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +7 -0
@@ -959,6 +959,13 @@ void __init setup_arch(char **cmdline_p) init_mm.end_code = (unsigned long ) _etext; init_mm.end_data = (unsigned long ) _edata; init_mm.brk = _brk_end; +#ifdef CONFIG_X86_INTEL_MPX +/* +* NULL is theoretically a valid place to put the bounds +* directory, so point this at an invalid address. +*/ + init_mm.bd_addr =MPX_INVALID_BOUNDS_DIR ; +#endif code_resource.start =__pa_symbol (_text); code_resource.end =__pa_symbol (_etext)-1 ;
arch/x86/kernel/traps.c renamed from arch/x86/kernel/traps.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +84 -1
103 lines not on this page · raw message
arch/x86/mm/mpx.c renamed from arch/x86/mm/mpx.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +220 -5
257 lines not on this page · raw message
fs/exec.c renamed from fs/exec.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +2 -0
@@ -60,6 +60,7 @@#include <asm/uaccess.h> #include <asm/mmu_context.h> #include <asm/tlb.h> +#include <asm/mpx.h> #include <trace/events/task.h> #include "internal.h"
@@ -277,6 +278,7 @@ static int __bprm_mm_init(struct linux_b goto err; mm->stack_vm = mm->total_vm =1 ; +arch_bprm_mm_init (mm, vma);up_write (&mm->mmap_sem); bprm->p = vma->vm_end -sizeof (void *);return 0 ;
include/asm-generic/mmu_context.h renamed from include/asm-generic/mmu_context.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +5 -0
@@ -42,4 +42,9 @@ static inline void activate_mm(struct mm { } +static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +} +#endif /* __ASM_GENERIC_MMU_CONTEXT_H */
include/linux/mm_types.h renamed from include/linux/mm_types.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +3 -0
@@ -454,6 +454,9 @@ struct mm_struct {bool tlb_flush_pending;#endif struct uprobes_state uprobes_state; +#ifdef CONFIG_X86_INTEL_MPX +void __user *bd_addr;/* address of the bounds directory */ +#endif };static inline void mm_init_cpumask (struct mm_struct *mm)
include/uapi/linux/prctl.h renamed from include/uapi/linux/prctl.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +6 -0
@@ -179,4 +179,10 @@ struct prctl_mm_map {#define PR_SET_THP_DISABLE 41#define PR_GET_THP_DISABLE 42 +/* +* Tell the kernel to start/stop helping userspace manage bounds tables. +*/ +#define PR_MPX_ENABLE_MANAGEMENT 43 +#define PR_MPX_DISABLE_MANAGEMENT 44 +#endif /* _LINUX_PRCTL_H */
kernel/sys.c renamed from kernel/sys.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +12 -0
@@ -91,6 +91,12 @@#ifndef SET_TSC_CTL # define SET_TSC_CTL (a) (-EINVAL)#endif +#ifndef MPX_ENABLE_MANAGEMENT +# define MPX_ENABLE_MANAGEMENT (a) (-EINVAL) +#endif +#ifndef MPX_DISABLE_MANAGEMENT +# define MPX_DISABLE_MANAGEMENT (a) (-EINVAL) +#endif /* * this is where the system-wide overflow UID and GID are defined, for
@@ -2203,6 +2209,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsi me->mm->def_flags &= ~VM_NOHUGEPAGE ;up_write (&me->mm->mmap_sem);break ; +case PR_MPX_ENABLE_MANAGEMENT : + error =MPX_ENABLE_MANAGEMENT (me); +break ; +case PR_MPX_DISABLE_MANAGEMENT : + error =MPX_DISABLE_MANAGEMENT (me); +break ;default : error = -EINVAL ;break ;
_
Re: [PATCH 09/11] x86, mpx: on-demand kernel allocation of bounds tables
arch/x86/include/asm/mmu_context.h do { \ · line 112
Quoted 9 lines · Dave Hansen
* move mm init-time #ifdef to
mpx.harch/x86/include/asm/mmu_context.h renamed from arch/x86/include/asm/mmu_context.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +7
-0+static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +mpx_mm_init (mm); +#ifdef CONFIG_X86_INTEL_MPX + mm->bd_addr =MPX_INVALID_BOUNDS_DIR ; +#endif
So we have a double init now :)
arch/x86/kernel/setup.c void __init setup_arch(char **cmdline_p) · line 968
Quoted 12 lines
+++
b/arch/x86/kernel/setup.c2014-11-14 07:06:23.941684394 -0800arch/x86/kernel/setup.c renamed from arch/x86/kernel/setup.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +7
-0@@ -959,6 +959,13 @@ void __init setup_arch(char **cmdline_p) init_mm.end_code = (unsigned long ) _etext; init_mm.end_data = (unsigned long ) _edata; init_mm.brk = _brk_end; +#ifdef CONFIG_X86_INTEL_MPX +/* +* NULL is theoretically a valid place to put the bounds +* directory, so point this at an invalid address. +*/ + init_mm.bd_addr =MPX_INVALID_BOUNDS_DIR ; +#endif
And this one wants mpx_mm_init() replacement as well.
Thanks,
tglx
Re: [PATCH 09/11] x86, mpx: on-demand kernel allocation of bounds tables
Quoted 12 lines · Thomas Gleixner
Review
Quoted 9 lines · Dave Hansen
* move mm init-time #ifdef to
mpx.h(quoted diff) +7
-0+static inline void arch_bprm_mm_init(struct mm_struct *mm, + struct vm_area_struct *vma) +{ + mpx_mm_init(mm); +#ifdef CONFIG_X86_INTEL_MPX + mm->bd_addr = MPX_INVALID_BOUNDS_DIR; +#endifSo we have a double init now :)
Bah, that kinda defeats the purpose now, doesn't it? :)
Quoted 6 lines
Quoted 6 lines
+++
b/arch/x86/kernel/setup.c2014-11-14 07:06:23.941684394 -0800(quoted diff) +1
-0@@ -959,6 +959,13 @@ void __init setup_arch(char **cmdline_p) init_mm.end_code = (unsigned long) _etext; init_mm.end_data = (unsigned long) _edata; init_mm.brk = _brk_end; +#ifdef CONFIG_X86_INTEL_MPX
Quoted 8 lines
Review void __init setup_arch(char **cmdline_p) · line 968
Quoted 6 lines
(quoted diff) +6
-0+ /* + * NULL is theoretically a valid place to put the bounds + * directory, so point this at an invalid address. + */ + init_mm.bd_addr = MPX_INVALID_BOUNDS_DIR; +#endifAnd this one wants
mpx_mm_init()replacement as well.
Rather than reposting the whole set, attached is a quick redo of the changes to just this patch.
If anyone wants the whole thing resent, or this one in another format, please holler.
From: Dave Hansen <[email protected]>
changes from v11:
* remove double-initialization and missed removal of #ifdef
* remove #ifdef in setup_arch()
changes from v10:
* move mm init-time #ifdef to mpx.h
* add comment in do_bounds() about why xsave is needed
* add missing return in do_bounds();
* unconvolute mpx_handle_bd_fault()
--
This is really the meat of the MPX patch set. If there is one patch to review in the entire series, this is the one. There is a new ABI here and this kernel code also interacts with userspace memory in a relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the management of bounds tables in kernel, including on-demand kernel allocation (See the patch "on-demand kernel allocation of bounds tables") and cleanup (See the patch "cleanup unused bound tables"). Applications do not strictly need the kernel to manage bounds tables and we expect some applications to use MPX without taking advantage of this kernel support. This means the kernel can not simply infer whether an application needs bounds table management from the MPX registers. The prctl() is an explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds directory out of a userspace register (bndcfgu) and then cache it into a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT will set "bd_addr" to an invalid address. Using this scheme, we can use "bd_addr" to determine whether the management of bounds tables in kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves, which can be expensive. Caching "bd_addr" like this also helps reduce the cost of those xsaves when doing table cleanup at munmap() time. Unfortunately, we can not apply this optimization to #BR fault time because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information. If MPX-enabled code needs more than these 4 registers, it needs to spill them somewhere. It has two special instructions for this which allow the bounds to be moved between the bounds registers and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by the MPX hardware during both bounds violations or when the tables are not present. This patch handles those #BR exceptions for not-present tables by carving the space out of the normal processes address space (essentially calling the new mmap() interface indroduced earlier in this patch set.) and then pointing the bounds-directory over to it.
The tables *need* to be accessed and controlled by userspace because the instructions for moving bounds in and out of them are extremely frequent. They potentially happen every time a register pointing to memory is dereferenced. Any direct kernel involvement (like a syscall) to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel. However, MPX does not strictly *require* anything in the kernel. It can theoretically be done completely from userspace. Here are a few ways this *could* be done. I don't think any of them are practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds directory. If we were to preallocate them for the 128TB of user virtual address space, we would need to reserve 512TB+2GB, which is larger than the entire virtual address space today. This means they can not be reserved ahead of time. Also, a single process's pre-popualated bounds directory consumes 2GB of virtual *AND* physical memory. IOW, it's completely infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small, constrained applications. But, it isn't practical at a larger scale since a given app has no way of controlling how all the parts of the app might allocate memory (think libraries). The kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still requires locking or nasty tricks to keep track of the allocation state there.
Having ruled out all of the userspace-only approaches for managing bounds tables that we could think of, we create them on demand in the kernel.
---
b/arch/x86/include/asm/mmu_context.h | 7 + b/arch/x86/include/asm/mpx.h | 41 ++++++ b/arch/x86/include/asm/processor.h | 18 ++ b/arch/x86/kernel/mpx.c | 1 b/arch/x86/kernel/setup.c | 2 b/arch/x86/kernel/traps.c | 85 +++++++++++++ b/arch/x86/mm/mpx.c | 225 ++++++++++++++++++++++++++++++++++- b/fs/exec.c | 2 b/include/asm-generic/mmu_context.h | 5 b/include/linux/mm_types.h | 3 b/include/uapi/linux/prctl.h | 6 b/kernel/sys.c | 12 + 12 files changed, 401 insertions(+), 6 deletions(-)
arch/x86/include/asm/mmu_context.h renamed from arch/x86/include/asm/mmu_context.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +7 -0
@@ -10,6 +10,7 @@#include <asm/pgalloc.h> #include <asm/tlbflush.h> #include <asm/paravirt.h> +#include <asm/mpx.h> #ifndef CONFIG_PARAVIRT #include <asm-generic/mm_hooks.h>
@@ -102,4 +103,10 @@ do { \ } while (0)#endif +static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +mpx_mm_init (mm); +} +#endif /* _ASM_X86_MMU_CONTEXT_H */
arch/x86/include/asm/mpx.h renamed from arch/x86/include/asm/mpx.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +41 -0
76 lines not on this page · raw message
arch/x86/include/asm/processor.h renamed from arch/x86/include/asm/processor.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +18 -0
@@ -954,6 +954,24 @@ extern void start_thread(struct pt_regsextern int get_tsc_mode (unsigned long adr);extern int set_tsc_mode (unsigned int val); +/* Register/unregister a process' MPX related resource */ +#define MPX_ENABLE_MANAGEMENT (tsk) mpx_enable_management((tsk)) +#define MPX_DISABLE_MANAGEMENT (tsk) mpx_disable_management((tsk)) + +#ifdef CONFIG_X86_INTEL_MPX +extern int mpx_enable_management (struct task_struct *tsk); +extern int mpx_disable_management (struct task_struct *tsk); +#else +static inline int mpx_enable_management (struct task_struct *tsk) +{ +return -EINVAL ; +} +static inline int mpx_disable_management (struct task_struct *tsk) +{ +return -EINVAL ; +} +#endif /* CONFIG_X86_INTEL_MPX */ +extern u16 amd_get_nb_id (int cpu);static inline uint32_t hypervisor_cpuid_base (const char *sig,uint32_t leaves)
arch/x86/kernel/mpx.c new file +1 -0
@@ -0,0 +1 @@ +
arch/x86/kernel/setup.c renamed from arch/x86/kernel/setup.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +2 -0
@@ -960,6 +960,8 @@ void __init setup_arch(char **cmdline_p) init_mm.end_data = (unsigned long ) _edata; init_mm.brk = _brk_end; +mpx_mm_init (&init_mm); + code_resource.start =__pa_symbol (_text); code_resource.end =__pa_symbol (_etext)-1 ; data_resource.start =__pa_symbol (_etext);
arch/x86/kernel/traps.c renamed from arch/x86/kernel/traps.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +84 -1
103 lines not on this page · raw message
arch/x86/mm/mpx.c renamed from arch/x86/mm/mpx.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +220 -5
257 lines not on this page · raw message
fs/exec.c renamed from fs/exec.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +2 -0
@@ -60,6 +60,7 @@#include <asm/uaccess.h> #include <asm/mmu_context.h> #include <asm/tlb.h> +#include <asm/mpx.h> #include <trace/events/task.h> #include "internal.h"
@@ -277,6 +278,7 @@ static int __bprm_mm_init(struct linux_b goto err; mm->stack_vm = mm->total_vm =1 ; +arch_bprm_mm_init (mm, vma);up_write (&mm->mmap_sem); bprm->p = vma->vm_end -sizeof (void *);return 0 ;
include/asm-generic/mmu_context.h renamed from include/asm-generic/mmu_context.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +5 -0
@@ -42,4 +42,9 @@ static inline void activate_mm(struct mm { } +static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +} +#endif /* __ASM_GENERIC_MMU_CONTEXT_H */
include/linux/mm_types.h renamed from include/linux/mm_types.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +3 -0
@@ -454,6 +454,9 @@ struct mm_struct {bool tlb_flush_pending;#endif struct uprobes_state uprobes_state; +#ifdef CONFIG_X86_INTEL_MPX +void __user *bd_addr;/* address of the bounds directory */ +#endif };static inline void mm_init_cpumask (struct mm_struct *mm)
include/uapi/linux/prctl.h renamed from include/uapi/linux/prctl.h~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +6 -0
@@ -179,4 +179,10 @@ struct prctl_mm_map {#define PR_SET_THP_DISABLE 41#define PR_GET_THP_DISABLE 42 +/* +* Tell the kernel to start/stop helping userspace manage bounds tables. +*/ +#define PR_MPX_ENABLE_MANAGEMENT 43 +#define PR_MPX_DISABLE_MANAGEMENT 44 +#endif /* _LINUX_PRCTL_H */
kernel/sys.c renamed from kernel/sys.c~mpx-v11-on-demand-kernel-allocation-of-bounds-tables +12 -0
@@ -91,6 +91,12 @@#ifndef SET_TSC_CTL # define SET_TSC_CTL (a) (-EINVAL)#endif +#ifndef MPX_ENABLE_MANAGEMENT +# define MPX_ENABLE_MANAGEMENT (a) (-EINVAL) +#endif +#ifndef MPX_DISABLE_MANAGEMENT +# define MPX_DISABLE_MANAGEMENT (a) (-EINVAL) +#endif /* * this is where the system-wide overflow UID and GID are defined, for
@@ -2203,6 +2209,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsi me->mm->def_flags &= ~VM_NOHUGEPAGE ;up_write (&me->mm->mmap_sem);break ; +case PR_MPX_ENABLE_MANAGEMENT : + error =MPX_ENABLE_MANAGEMENT (me); +break ; +case PR_MPX_DISABLE_MANAGEMENT : + error =MPX_DISABLE_MANAGEMENT (me); +break ;default : error = -EINVAL ;break ;
_
tip-bot for Dave Hansen
merge bot[tip:x86/mpx] x86, mpx: On-demand kernel allocation of bounds tables
In reply to Dave Hansenx86, mpx: On-demand kernel allocation of bounds tables
Commit-ID: fe3d197f84319d3bce379a9c0dc17b1f48ad358c Gitweb: http://git.kernel.org/tip/fe3d197f84319d3bce379a9c0dc17b1f48ad358c Author: Dave Hansen <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:29 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:53 +0100
x86, mpx: On-demand kernel allocation of bounds tables
This is really the meat of the MPX patch set. If there is one patch to review in the entire series, this is the one. There is a new ABI here and this kernel code also interacts with userspace memory in a relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the management of bounds tables in kernel, including on-demand kernel allocation (See the patch "on-demand kernel allocation of bounds tables") and cleanup (See the patch "cleanup unused bound tables"). Applications do not strictly need the kernel to manage bounds tables and we expect some applications to use MPX without taking advantage of this kernel support. This means the kernel can not simply infer whether an application needs bounds table management from the MPX registers. The prctl() is an explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds directory out of a userspace register (bndcfgu) and then cache it into a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT will set "bd_addr" to an invalid address. Using this scheme, we can use "bd_addr" to determine whether the management of bounds tables in kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves, which can be expensive. Caching "bd_addr" like this also helps reduce the cost of those xsaves when doing table cleanup at munmap() time. Unfortunately, we can not apply this optimization to #BR fault time because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information. If MPX-enabled code needs more than these 4 registers, it needs to spill them somewhere. It has two special instructions for this which allow the bounds to be moved between the bounds registers and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by the MPX hardware during both bounds violations or when the tables are not present. This patch handles those #BR exceptions for not-present tables by carving the space out of the normal processes address space (essentially calling the new mmap() interface indroduced earlier in this patch set.) and then pointing the bounds-directory over to it.
The tables *need* to be accessed and controlled by userspace because the instructions for moving bounds in and out of them are extremely frequent. They potentially happen every time a register pointing to memory is dereferenced. Any direct kernel involvement (like a syscall) to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel. However, MPX does not strictly *require* anything in the kernel. It can theoretically be done completely from userspace. Here are a few ways this *could* be done. I don't think any of them are practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds directory. If we were to preallocate them for the 128TB of user virtual address space, we would need to reserve 512TB+2GB, which is larger than the entire virtual address space today. This means they can not be reserved ahead of time. Also, a single process's pre-popualated bounds directory consumes 2GB of virtual *AND* physical memory. IOW, it's completely infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small, constrained applications. But, it isn't practical at a larger scale since a given app has no way of controlling how all the parts of the app might allocate memory (think libraries). The kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still requires locking or nasty tricks to keep track of the allocation state there.
Having ruled out all of the userspace-only approaches for managing bounds tables that we could think of, we create them on demand in the kernel.
--- arch/x86/include/asm/mmu_context.h | 7 ++ arch/x86/include/asm/mpx.h | 41 +++++++ arch/x86/include/asm/processor.h | 18 +++ arch/x86/kernel/setup.c | 2 + arch/x86/kernel/traps.c | 85 +++++++++++++- arch/x86/mm/mpx.c | 223 ++++++++++++++++++++++++++++++++++++- fs/exec.c | 2 + include/asm-generic/mmu_context.h | 5 + include/linux/mm_types.h | 4 + include/uapi/linux/prctl.h | 6 + kernel/sys.c | 12 ++ 11 files changed, 399 insertions(+), 6 deletions(-)
arch/x86/include/asm/mmu_context.h +7 -0
@@ -10,6 +10,7 @@#include <asm/pgalloc.h> #include <asm/tlbflush.h> #include <asm/paravirt.h> +#include <asm/mpx.h> #ifndef CONFIG_PARAVIRT #include <asm-generic/mm_hooks.h>
@@ -102,4 +103,10 @@ do { \ } while (0)#endif +static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +mpx_mm_init (mm); +} +#endif /* _ASM_X86_MMU_CONTEXT_H */
arch/x86/include/asm/mpx.h +41 -0
76 lines not on this page · raw message
arch/x86/include/asm/processor.h +18 -0
@@ -954,6 +954,24 @@ extern void start_thread(struct pt_regs *regs, unsigned long new_ip,extern int get_tsc_mode (unsigned long adr);extern int set_tsc_mode (unsigned int val); +/* Register/unregister a process' MPX related resource */ +#define MPX_ENABLE_MANAGEMENT (tsk) mpx_enable_management((tsk)) +#define MPX_DISABLE_MANAGEMENT (tsk) mpx_disable_management((tsk)) + +#ifdef CONFIG_X86_INTEL_MPX +extern int mpx_enable_management (struct task_struct *tsk); +extern int mpx_disable_management (struct task_struct *tsk); +#else +static inline int mpx_enable_management (struct task_struct *tsk) +{ +return -EINVAL ; +} +static inline int mpx_disable_management (struct task_struct *tsk) +{ +return -EINVAL ; +} +#endif /* CONFIG_X86_INTEL_MPX */ +extern u16 amd_get_nb_id (int cpu);static inline uint32_t hypervisor_cpuid_base (const char *sig,uint32_t leaves)
arch/x86/kernel/setup.c +2 -0
@@ -960,6 +960,8 @@ void __init setup_arch(char **cmdline_p) init_mm.end_data = (unsigned long ) _edata; init_mm.brk = _brk_end; +mpx_mm_init (&init_mm); + code_resource.start =__pa_symbol (_text); code_resource.end =__pa_symbol (_etext)-1 ; data_resource.start =__pa_symbol (_etext);
arch/x86/kernel/traps.c +84 -1
103 lines not on this page · raw message
arch/x86/mm/mpx.c +218 -5
257 lines not on this page · raw message
fs/exec.c +2 -0
@@ -60,6 +60,7 @@#include <asm/uaccess.h> #include <asm/mmu_context.h> #include <asm/tlb.h> +#include <asm/mpx.h> #include <trace/events/task.h> #include "internal.h"
@@ -277,6 +278,7 @@ static int __bprm_mm_init(struct linux_binprm *bprm) goto err; mm->stack_vm = mm->total_vm =1 ; +arch_bprm_mm_init (mm, vma);up_write (&mm->mmap_sem); bprm->p = vma->vm_end -sizeof (void *);return 0 ;
include/asm-generic/mmu_context.h +5 -0
@@ -42,4 +42,9 @@ static inline void activate_mm(struct mm_struct *prev_mm, { } +static inline void arch_bprm_mm_init (struct mm_struct *mm, +struct vm_area_struct *vma) +{ +} +#endif /* __ASM_GENERIC_MMU_CONTEXT_H */
include/linux/mm_types.h +4 -0
@@ -454,6 +454,10 @@ struct mm_struct {bool tlb_flush_pending;#endif struct uprobes_state uprobes_state; +#ifdef CONFIG_X86_INTEL_MPX +/* address of the bounds directory */ +void __user *bd_addr; +#endif };static inline void mm_init_cpumask (struct mm_struct *mm)
include/uapi/linux/prctl.h +6 -0
@@ -179,4 +179,10 @@ struct prctl_mm_map {#define PR_SET_THP_DISABLE 41#define PR_GET_THP_DISABLE 42 +/* +* Tell the kernel to start/stop helping userspace manage bounds tables. +*/ +#define PR_MPX_ENABLE_MANAGEMENT 43 +#define PR_MPX_DISABLE_MANAGEMENT 44 +#endif /* _LINUX_PRCTL_H */
kernel/sys.c +12 -0
@@ -91,6 +91,12 @@#ifndef SET_TSC_CTL # define SET_TSC_CTL (a) (-EINVAL)#endif +#ifndef MPX_ENABLE_MANAGEMENT +# define MPX_ENABLE_MANAGEMENT (a) (-EINVAL) +#endif +#ifndef MPX_DISABLE_MANAGEMENT +# define MPX_DISABLE_MANAGEMENT (a) (-EINVAL) +#endif /* * this is where the system-wide overflow UID and GID are defined, for
@@ -2203,6 +2209,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, me->mm->def_flags &= ~VM_NOHUGEPAGE ;up_write (&me->mm->mmap_sem);break ; +case PR_MPX_ENABLE_MANAGEMENT : + error =MPX_ENABLE_MANAGEMENT (me); +break ; +case PR_MPX_DISABLE_MANAGEMENT : + error =MPX_DISABLE_MANAGEMENT (me); +break ;default : error = -EINVAL ;break ;
PATCH v11 10/11 x86, mpx: cleanup unused bound tables
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
The previous patch allocates bounds tables on-demand. As noted in an earlier description, these can add up to *HUGE* amounts of memory. This has caused OOMs in practice when running tests.
This patch adds support for freeing bounds tables when they are no longer in use.
There are two types of mappings in play when unmapping tables:
1. The mapping with the actual data, which userspace is munmap()ing or brk()ing away, etc...
2. The mapping for the bounds table *backing* the data (is tagged with VM_MPX, see the patch "add MPX specific mmap interface").
If userspace use the prctl() indroduced earlier in this patchset to enable the management of bounds tables in kernel, when it unmaps the first type of mapping with the actual data, the kernel needs to free the mapping for the bounds table backing the data. This patch hooks in at the very end of do_unmap() to do so. We look at the addresses being unmapped and find the bounds directory entries and tables which cover those addresses. If an entire table is unused, we clear associated directory entry and free the table.
Once we unmap the bounds table, we would have a bounds directory entry pointing at empty address space. That address space might now be allocated for some other (random) use, and the MPX hardware might now try to walk it as if it were a bounds table. That would be bad. So any unmapping of an enture bounds table has to be accompanied by a corresponding write to the bounds directory entry to invalidate it. That write to the bounds directory can fault, which causes the following problem:
Since we are doing the freeing from munmap() (and other paths like it), we hold mmap_sem for write. If we fault, the page fault handler will attempt to acquire mmap_sem for read and we will deadlock. To avoid the deadlock, we pagefault_disable() when touching the bounds directory entry and use a get_user_pages() to resolve the fault.
The unmapping of bounds tables happends under vm_munmap(). We also (indirectly) call vm_munmap() to _do_ the unmapping of the bounds tables. We avoid unbounded recursion by disallowing freeing of bounds tables *for* bounds tables. This would not occur normally, so should not have any practical impact. Being strict about it here helps ensure that we do not have an exploitable stack overflow.
---
b/arch/x86/include/asm/mmu_context.h | 7 b/arch/x86/include/asm/mpx.h | 14 + b/arch/x86/mm/mpx.c | 393 +++++++++++++++++++++++++++++++++++ b/include/asm-generic/mmu_context.h | 6 b/mm/mmap.c | 2 5 files changed, 422 insertions(+)
arch/x86/include/asm/mmu_context.h renamed from arch/x86/include/asm/mmu_context.h~mpx-v11-cleanup-unused-bound-tables +7 -0
@@ -112,4 +112,11 @@ static inline void arch_bprm_mm_init(str #endif } +static inline void arch_unmap (struct mm_struct *mm, +struct vm_area_struct *vma, +unsigned long start,unsigned long end) +{ +mpx_notify_unmap (mm, vma, start, end); +} +#endif /* _ASM_X86_MMU_CONTEXT_H */
arch/x86/include/asm/mpx.h renamed from arch/x86/include/asm/mpx.h~mpx-v11-cleanup-unused-bound-tables +14 -0
@@ -51,6 +51,13 @@#define MPX_BNDCFG_ADDR_MASK (~((1UL<<MPX_BNDCFG_TAIL)-1))#define MPX_BNDSTA_ERROR_CODE 0x3 +#define MPX_BD_ENTRY_MASK ((1<<MPX_BD_ENTRY_OFFSET)-1) +#define MPX_BT_ENTRY_MASK ((1<<MPX_BT_ENTRY_OFFSET)-1) +#define MPX_GET_BD_ENTRY_OFFSET (addr) ((((addr)>>(MPX_BT_ENTRY_OFFSET+ \ + MPX_IGN_BITS)) & MPX_BD_ENTRY_MASK) << MPX_BD_ENTRY_SHIFT) +#define MPX_GET_BT_ENTRY_OFFSET (addr) ((((addr)>>MPX_IGN_BITS) & \ + MPX_BT_ENTRY_MASK) << MPX_BT_ENTRY_SHIFT) +#ifdef CONFIG_X86_INTEL_MPX siginfo_t *mpx_generate_siginfo (struct pt_regs *regs,struct xsave_struct *xsave_buf);
@@ -63,6 +70,8 @@ static inline void mpx_mm_init(struct mm { mm->bd_addr =MPX_INVALID_BOUNDS_DIR ; } +void mpx_notify_unmap (struct mm_struct *mm,struct vm_area_struct *vma, +unsigned long start,unsigned long end);#else static inline siginfo_t *mpx_generate_siginfo (struct pt_regs *regs,struct xsave_struct *xsave_buf)
@@ -80,6 +89,11 @@ static inline int kernel_managing_mpx_tastatic inline void mpx_mm_init (struct mm_struct *mm) { } +static inline void mpx_notify_unmap (struct mm_struct *mm, +struct vm_area_struct *vma, +unsigned long start,unsigned long end) +{ +}#endif /* CONFIG_X86_INTEL_MPX */ #endif /* _ASM_X86_MPX_H */
arch/x86/mm/mpx.c renamed from arch/x86/mm/mpx.c~mpx-v11-cleanup-unused-bound-tables +393 -0
408 lines not on this page · raw message
include/asm-generic/mmu_context.h renamed from include/asm-generic/mmu_context.h~mpx-v11-cleanup-unused-bound-tables +6 -0
@@ -47,4 +47,10 @@ static inline void arch_bprm_mm_init(str { } +static inline void arch_unmap (struct mm_struct *mm, +struct vm_area_struct *vma, +unsigned long start,unsigned long end) +{ +} +#endif /* __ASM_GENERIC_MMU_CONTEXT_H */
mm/mmap.c renamed from mm/mmap.c~mpx-v11-cleanup-unused-bound-tables +2 -0
@@ -2597,6 +2597,8 @@ int do_munmap(struct mm_struct *mm, unsidetach_vmas_to_be_unmapped (mm, vma, prev, end);unmap_region (mm, vma, prev, start, end); +arch_unmap (mm, vma, start, end); +/* Fix up all other VM information */ remove_vma_list (mm, vma);
_
tip-bot for Dave Hansen
merge bot[tip:x86/mpx] x86, mpx: Cleanup unused bound tables
x86, mpx: Cleanup unused bound tables
Commit-ID: 1de4fa14ee25a8edf287855513b61c3945c8878a Gitweb: http://git.kernel.org/tip/1de4fa14ee25a8edf287855513b61c3945c8878a Author: Dave Hansen <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:31 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:54 +0100
x86, mpx: Cleanup unused bound tables
The previous patch allocates bounds tables on-demand. As noted in an earlier description, these can add up to *HUGE* amounts of memory. This has caused OOMs in practice when running tests.
This patch adds support for freeing bounds tables when they are no longer in use.
There are two types of mappings in play when unmapping tables:
1. The mapping with the actual data, which userspace is munmap()ing or brk()ing away, etc...
2. The mapping for the bounds table *backing* the data (is tagged with VM_MPX, see the patch "add MPX specific mmap interface").
If userspace use the prctl() indroduced earlier in this patchset to enable the management of bounds tables in kernel, when it unmaps the first type of mapping with the actual data, the kernel needs to free the mapping for the bounds table backing the data. This patch hooks in at the very end of do_unmap() to do so. We look at the addresses being unmapped and find the bounds directory entries and tables which cover those addresses. If an entire table is unused, we clear associated directory entry and free the table.
Once we unmap the bounds table, we would have a bounds directory entry pointing at empty address space. That address space might now be allocated for some other (random) use, and the MPX hardware might now try to walk it as if it were a bounds table. That would be bad. So any unmapping of an enture bounds table has to be accompanied by a corresponding write to the bounds directory entry to invalidate it. That write to the bounds directory can fault, which causes the following problem:
Since we are doing the freeing from munmap() (and other paths like it), we hold mmap_sem for write. If we fault, the page fault handler will attempt to acquire mmap_sem for read and we will deadlock. To avoid the deadlock, we pagefault_disable() when touching the bounds directory entry and use a get_user_pages() to resolve the fault.
The unmapping of bounds tables happends under vm_munmap(). We also (indirectly) call vm_munmap() to _do_ the unmapping of the bounds tables. We avoid unbounded recursion by disallowing freeing of bounds tables *for* bounds tables. This would not occur normally, so should not have any practical impact. Being strict about it here helps ensure that we do not have an exploitable stack overflow.
--- arch/x86/include/asm/mmu_context.h | 6 + arch/x86/include/asm/mpx.h | 14 ++ arch/x86/mm/mpx.c | 393 +++++++++++++++++++++++++++++++++++++ include/asm-generic/mmu_context.h | 6 + mm/mmap.c | 2 + 5 files changed, 421 insertions(+)
arch/x86/include/asm/mmu_context.h +6 -0
@@ -109,4 +109,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm, mpx_mm_init(mm); } +static inline void arch_unmap (struct mm_struct *mm,struct vm_area_struct *vma, +unsigned long start,unsigned long end) +{ +mpx_notify_unmap (mm, vma, start, end); +} +#endif /* _ASM_X86_MMU_CONTEXT_H */
arch/x86/include/asm/mpx.h +14 -0
@@ -51,6 +51,13 @@#define MPX_BNDCFG_ADDR_MASK (~((1UL<<MPX_BNDCFG_TAIL)-1))#define MPX_BNDSTA_ERROR_CODE 0x3 +#define MPX_BD_ENTRY_MASK ((1<<MPX_BD_ENTRY_OFFSET)-1) +#define MPX_BT_ENTRY_MASK ((1<<MPX_BT_ENTRY_OFFSET)-1) +#define MPX_GET_BD_ENTRY_OFFSET (addr) ((((addr)>>(MPX_BT_ENTRY_OFFSET+ \ + MPX_IGN_BITS)) & MPX_BD_ENTRY_MASK) << MPX_BD_ENTRY_SHIFT) +#define MPX_GET_BT_ENTRY_OFFSET (addr) ((((addr)>>MPX_IGN_BITS) & \ + MPX_BT_ENTRY_MASK) << MPX_BT_ENTRY_SHIFT) +#ifdef CONFIG_X86_INTEL_MPX siginfo_t *mpx_generate_siginfo (struct pt_regs *regs,struct xsave_struct *xsave_buf);
@@ -67,6 +74,8 @@ static inline void mpx_mm_init(struct mm_struct *mm)*/ mm->bd_addr = MPX_INVALID_BOUNDS_DIR; } +void mpx_notify_unmap (struct mm_struct *mm,struct vm_area_struct *vma, +unsigned long start,unsigned long end);#else static inline siginfo_t *mpx_generate_siginfo (struct pt_regs *regs,struct xsave_struct *xsave_buf)
@@ -84,6 +93,11 @@ static inline int kernel_managing_mpx_tables(struct mm_struct *mm)static inline void mpx_mm_init (struct mm_struct *mm) { } +static inline void mpx_notify_unmap (struct mm_struct *mm, +struct vm_area_struct *vma, +unsigned long start,unsigned long end) +{ +}#endif /* CONFIG_X86_INTEL_MPX */ #endif /* _ASM_X86_MPX_H */
arch/x86/mm/mpx.c +393 -0
408 lines not on this page · raw message
include/asm-generic/mmu_context.h +6 -0
@@ -47,4 +47,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm, { } +static inline void arch_unmap (struct mm_struct *mm, +struct vm_area_struct *vma, +unsigned long start,unsigned long end) +{ +} +#endif /* __ASM_GENERIC_MMU_CONTEXT_H */
mm/mmap.c +2 -0
@@ -2597,6 +2597,8 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)detach_vmas_to_be_unmapped (mm, vma, prev, end);unmap_region (mm, vma, prev, start, end); +arch_unmap (mm, vma, start, end); +/* Fix up all other VM information */ remove_vma_list (mm, vma);
PATCH v11 11/11 x86, mpx: add documentation on Intel MPX
In reply to Dave HansenFrom: Dave Hansen <[email protected]>
This patch adds the Documentation/x86/intel_mpx.txt file with some information about Intel MPX.
---
b/Documentation/x86/intel_mpx.txt | 234 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 234 insertions(+)
Documentation/x86/intel_mpx.txt new file +234 -0
@@ -0,0 +1,234 @@ +1. Intel(R) MPX Overview +============ + +Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new capability +introduced into Intel Architecture. Intel MPX provides hardware features +that can be used in conjunction with compiler changes to check memory +references, for those references whose compile-time normal intentions are +usurped at runtime due to buffer overflow or underflow. + +For more information, please refer to Intel(R) Architecture Instruction +Set Extensions Programming Reference, Chapter 9: Intel(R) Memory Protection +Extensions. + +Note: Currently no hardware with MPX ISA is available but it is always +possible to use SDE (Intel(R) Software Development Emulator) instead, which +can be downloaded from +http://software.intel.com/en-us/articles/intel-software-development-emulator + + +2. How to get the advantage of MPX +================= + +For MPX to work, changes are required in the kernel, binutils and compiler. +No source changes are required for applications, just a recompile. + +There are a lot of moving parts of this to all work right. The following +is how we expect the compiler, application and kernel to work together. + +1) Application developer compiles with -fmpx. The compiler will add the + instrumentation as well as some setup code called early after the app + starts. New instruction prefixes are noops for old CPUs. +2) That setup code allocates (virtual) space for the "bounds directory", + points the "bndcfgu" register to the directory and notifies the kernel + (via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using + MPX. +3) The kernel detects that the CPU has MPX, allows the new prctl() to + succeed, and notes the location of the bounds directory. Userspace is + expected to keep the bounds directory at that locationWe note it + instead of reading it each time because the 'xsave' operation needed + to access the bounds directory register is an expensive operation. +4) If the application needs to spill bounds out of the 4 registers, it + issues a bndstx instruction. Since the bounds directory is empty at + this point, a bounds fault (#BR) is raised, the kernel allocates a + bounds table (in the user address space) and makes the relevant entry + in the bounds directory point to the new table. +5) If the application violates the bounds specified in the bounds registers, + a separate kind of #BR is raised which will deliver a signal with + information about the violation in the 'struct siginfo'. +6) Whenever memory is freed, we know that it can no longer contain valid + pointers, and we attempt to free the associated space in the bounds + tables. If an entire table becomes unused, we will attempt to free + the table and remove the entry in the directory. + +To summarize, there are essentially three things interacting here: + +GCC with -fmpx: + * enables annotation of code with MPX instructions and prefixes + * inserts code early in the application to call in to the "gcc runtime" +GCC MPX Runtime: + * Checks for hardware MPX support in cpuid leaf + * allocates virtual space for the bounds directory (malloc() essentially) + * points the hardware BNDCFGU register at the directory + * calls a new prctl(PR_MPX_ENABLE_MANAGEMENT) to notify the kernel to + start managing the bounds directories +Kernel MPX Code: + * Checks for hardware MPX support in cpuid leaf + * Handles #BR exceptions and sends SIGSEGV to the app when it violates + bounds, like during a buffer overflow. + * When bounds are spilled in to an unallocated bounds table, the kernel + notices in the #BR exception, allocates the virtual space, then + updates the bounds directory to point to the new table. It keeps + special track of the memory with a VM_MPX flag. + * Frees unused bounds tables at the time that the memory they described + is unmapped. + + +3. How does MPX kernel code work +================ + +Handling #BR faults caused by MPX +--------------------------------- + +When MPX is enabled, there are 2 new situations that can generate +#BR faults. + * new bounds tables (BT) need to be allocated to save bounds. + * bounds violation caused by MPX instructions. + +We hook #BR handler to handle these two new situations. + +On-demand kernel allocation of bounds tables +-------------------------------------------- + +MPX only has 4 hardware registers for storing bounds information. If +MPX-enabled code needs more than these 4 registers, it needs to spill +them somewhere. It has two special instructions for this which allow +the bounds to be moved between the bounds registers and some new "bounds +tables". + +#BR exceptions are a new class of exceptions just for MPX. They are +similar conceptually to a page fault and will be raised by the MPX +hardware during both bounds violations or when the tables are not +present. The kernel handles those #BR exceptions for not-present tables +by carving the space out of the normal processes address space and then +pointing the bounds-directory over to it. + +The tables need to be accessed and controlled by userspace because +the instructions for moving bounds in and out of them are extremely +frequent. They potentially happen every time a register points to +memory. Any direct kernel involvement (like a syscall) to access the +tables would obviously destroy performance. + +Why not do this in userspace? MPX does not strictly require anything in +the kernel. It can theoretically be done completely from userspace. Here +are a few ways this could be done. We don't think any of them are practical +in the real-world, but here they are. + +Q: Can virtual space simply be reserved for the bounds tables so that we + never have to allocate them? +A: MPX-enabled application will possibly create a lot of bounds tables in + process address space to save bounds information. These tables can take + up huge swaths of memory (as much as 80% of the memory on the system) + even if we clean them up aggressively. In the worst-case scenario, the + tables can be 4x the size of the data structure being tracked. IOW, a + 1-page structure can require 4 bounds-table pages. An X-GB virtual + area needs 4*X GB of virtual space, plus 2GB for the bounds directory. + If we were to preallocate them for the 128TB of user virtual address + space, we would need to reserve 512TB+2GB, which is larger than the + entire virtual address space today. This means they can not be reserved + ahead of time. Also, a single process's pre-popualated bounds directory + consumes 2GB of virtual *AND* physical memory. IOW, it's completely + infeasible to prepopulate bounds directories. + +Q: Can we preallocate bounds table space at the same time memory is + allocated which might contain pointers that might eventually need + bounds tables? +A: This would work if we could hook the site of each and every memory + allocation syscall. This can be done for small, constrained applications. + But, it isn't practical at a larger scale since a given app has no + way of controlling how all the parts of the app might allocate memory + (think libraries). The kernel is really the only place to intercept + these calls. + +Q: Could a bounds fault be handed to userspace and the tables allocated + there in a signal handler intead of in the kernel? +A: mmap() is not on the list of safe async handler functions and even + if mmap() would work it still requires locking or nasty tricks to + keep track of the allocation state there. + +Having ruled out all of the userspace-only approaches for managing +bounds tables that we could think of, we create them on demand in +the kernel. + +Decoding MPX instructions +------------------------- + +If a #BR is generated due to a bounds violation caused by MPX. +We need to decode MPX instructions to get violation address and +set this address into extended struct siginfo. + +The _sigfault feild of struct siginfo is extended as follow: + +87 /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */ +88 struct { +89 void __user *_addr; /* faulting insn/memory ref. */ +90 #ifdef __ARCH_SI_TRAPNO +91 int _trapno; /* TRAP # which caused the signal */ +92 #endif +93 short _addr_lsb; /* LSB of the reported address */ +94 struct { +95 void __user *_lower; +96 void __user *_upper; +97 } _addr_bnd; +98 } _sigfault; + +The '_addr' field refers to violation address, and new '_addr_and' +field refers to the upper/lower bounds when a #BR is caused. + +Glibc will be also updated to support this new siginfo. So user +can get violation address and bounds when bounds violations occur. + +Cleanup unused bounds tables +---------------------------- + +When a BNDSTX instruction attempts to save bounds to a bounds directory +entry marked as invalid, a #BR is generated. This is an indication that +no bounds table exists for this entry. In this case the fault handler +will allocate a new bounds table on demand. + +Since the kernel allocated those tables on-demand without userspace +knowledge, it is also responsible for freeing them when the associated +mappings go away. + +Here, the solution for this issue is to hook do_munmap() to check +whether one process is MPX enabled. If yes, those bounds tables covered +in the virtual address region which is being unmapped will be freed also. + +Adding new prctl commands +------------------------- + +Two new prctl commands are added to enable and disable MPX bounds tables +management in kernel. + +155 #define PR_MPX_ENABLE_MANAGEMENT 43 +156 #define PR_MPX_DISABLE_MANAGEMENT 44 + +Runtime library in userspace is responsible for allocation of bounds +directory. So kernel have to use XSAVE instruction to get the base +of bounds directory from BNDCFG register. + +But XSAVE is expected to be very expensive. In order to do performance +optimization, we have to get the base of bounds directory and save it +into struct mm_struct to be used in future during PR_MPX_ENABLE_MANAGEMENT +command execution. + + +4. Special rules +======== + +1) If userspace is requesting help from the kernel to do the management +of bounds tables, it may not create or modify entries in the bounds directory. + +Certainly users can allocate bounds tables and forcibly point the bounds +directory at them through XSAVE instruction, and then set valid bit +of bounds entry to have this entry valid. But, the kernel will decline +to assist in managing these tables. + +2) Userspace may not take multiple bounds directory entries and point +them at the same bounds table. + +This is allowed architecturally. See more information "Intel(R) Architecture +Instruction Set Extensions Programming Reference" (9.3.4). + +However, if users did this, the kernel might be fooled in to unmaping an +in-use bounds table since it does not recognize sharing.
_
tip-bot for Qiaowei Ren
merge bot[tip:x86/mpx] x86, mpx: Add documentation on Intel MPX
x86, mpx: Add documentation on Intel MPX
Commit-ID: 5776563648f6437ede91c91cbad85862ca682b0b Gitweb: http://git.kernel.org/tip/5776563648f6437ede91c91cbad85862ca682b0b Author: Qiaowei Ren <[email protected]> AuthorDate: Fri, 14 Nov 2014 07:18:32 -0800 Committer: Thomas Gleixner <[email protected]> CommitDate: Tue, 18 Nov 2014 00:58:54 +0100
x86, mpx: Add documentation on Intel MPX
This patch adds the Documentation/x86/intel_mpx.txt file with some information about Intel MPX.
--- Documentation/x86/intel_mpx.txt | 234 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 234 insertions(+)
Documentation/x86/intel_mpx.txt new file +234 -0
@@ -0,0 +1,234 @@ +1. Intel(R) MPX Overview +======================== + +Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new capability +introduced into Intel Architecture. Intel MPX provides hardware features +that can be used in conjunction with compiler changes to check memory +references, for those references whose compile-time normal intentions are +usurped at runtime due to buffer overflow or underflow. + +For more information, please refer to Intel(R) Architecture Instruction +Set Extensions Programming Reference, Chapter 9: Intel(R) Memory Protection +Extensions. + +Note: Currently no hardware with MPX ISA is available but it is always +possible to use SDE (Intel(R) Software Development Emulator) instead, which +can be downloaded from +http://software.intel.com/en-us/articles/intel-software-development-emulator + + +2. How to get the advantage of MPX +================================== + +For MPX to work, changes are required in the kernel, binutils and compiler. +No source changes are required for applications, just a recompile. + +There are a lot of moving parts of this to all work right. The following +is how we expect the compiler, application and kernel to work together. + +1) Application developer compiles with -fmpx. The compiler will add the + instrumentation as well as some setup code called early after the app + starts. New instruction prefixes are noops for old CPUs. +2) That setup code allocates (virtual) space for the "bounds directory", + points the "bndcfgu" register to the directory and notifies the kernel + (via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using + MPX. +3) The kernel detects that the CPU has MPX, allows the new prctl() to + succeed, and notes the location of the bounds directory. Userspace is + expected to keep the bounds directory at that locationWe note it + instead of reading it each time because the 'xsave' operation needed + to access the bounds directory register is an expensive operation. +4) If the application needs to spill bounds out of the 4 registers, it + issues a bndstx instruction. Since the bounds directory is empty at + this point, a bounds fault (#BR) is raised, the kernel allocates a + bounds table (in the user address space) and makes the relevant entry + in the bounds directory point to the new table. +5) If the application violates the bounds specified in the bounds registers, + a separate kind of #BR is raised which will deliver a signal with + information about the violation in the 'struct siginfo'. +6) Whenever memory is freed, we know that it can no longer contain valid + pointers, and we attempt to free the associated space in the bounds + tables. If an entire table becomes unused, we will attempt to free + the table and remove the entry in the directory. + +To summarize, there are essentially three things interacting here: + +GCC with -fmpx: + * enables annotation of code with MPX instructions and prefixes + * inserts code early in the application to call in to the "gcc runtime" +GCC MPX Runtime: + * Checks for hardware MPX support in cpuid leaf + * allocates virtual space for the bounds directory (malloc() essentially) + * points the hardware BNDCFGU register at the directory + * calls a new prctl(PR_MPX_ENABLE_MANAGEMENT) to notify the kernel to + start managing the bounds directories +Kernel MPX Code: + * Checks for hardware MPX support in cpuid leaf + * Handles #BR exceptions and sends SIGSEGV to the app when it violates + bounds, like during a buffer overflow. + * When bounds are spilled in to an unallocated bounds table, the kernel + notices in the #BR exception, allocates the virtual space, then + updates the bounds directory to point to the new table. It keeps + special track of the memory with a VM_MPX flag. + * Frees unused bounds tables at the time that the memory they described + is unmapped. + + +3. How does MPX kernel code work +================================ + +Handling #BR faults caused by MPX +--------------------------------- + +When MPX is enabled, there are 2 new situations that can generate +#BR faults. + * new bounds tables (BT) need to be allocated to save bounds. + * bounds violation caused by MPX instructions. + +We hook #BR handler to handle these two new situations. + +On-demand kernel allocation of bounds tables +-------------------------------------------- + +MPX only has 4 hardware registers for storing bounds information. If +MPX-enabled code needs more than these 4 registers, it needs to spill +them somewhere. It has two special instructions for this which allow +the bounds to be moved between the bounds registers and some new "bounds +tables". + +#BR exceptions are a new class of exceptions just for MPX. They are +similar conceptually to a page fault and will be raised by the MPX +hardware during both bounds violations or when the tables are not +present. The kernel handles those #BR exceptions for not-present tables +by carving the space out of the normal processes address space and then +pointing the bounds-directory over to it. + +The tables need to be accessed and controlled by userspace because +the instructions for moving bounds in and out of them are extremely +frequent. They potentially happen every time a register points to +memory. Any direct kernel involvement (like a syscall) to access the +tables would obviously destroy performance. + +Why not do this in userspace? MPX does not strictly require anything in +the kernel. It can theoretically be done completely from userspace. Here +are a few ways this could be done. We don't think any of them are practical +in the real-world, but here they are. + +Q: Can virtual space simply be reserved for the bounds tables so that we + never have to allocate them? +A: MPX-enabled application will possibly create a lot of bounds tables in + process address space to save bounds information. These tables can take + up huge swaths of memory (as much as 80% of the memory on the system) + even if we clean them up aggressively. In the worst-case scenario, the + tables can be 4x the size of the data structure being tracked. IOW, a + 1-page structure can require 4 bounds-table pages. An X-GB virtual + area needs 4*X GB of virtual space, plus 2GB for the bounds directory. + If we were to preallocate them for the 128TB of user virtual address + space, we would need to reserve 512TB+2GB, which is larger than the + entire virtual address space today. This means they can not be reserved + ahead of time. Also, a single process's pre-popualated bounds directory + consumes 2GB of virtual *AND* physical memory. IOW, it's completely + infeasible to prepopulate bounds directories. + +Q: Can we preallocate bounds table space at the same time memory is + allocated which might contain pointers that might eventually need + bounds tables? +A: This would work if we could hook the site of each and every memory + allocation syscall. This can be done for small, constrained applications. + But, it isn't practical at a larger scale since a given app has no + way of controlling how all the parts of the app might allocate memory + (think libraries). The kernel is really the only place to intercept + these calls. + +Q: Could a bounds fault be handed to userspace and the tables allocated + there in a signal handler intead of in the kernel? +A: mmap() is not on the list of safe async handler functions and even + if mmap() would work it still requires locking or nasty tricks to + keep track of the allocation state there. + +Having ruled out all of the userspace-only approaches for managing +bounds tables that we could think of, we create them on demand in +the kernel. + +Decoding MPX instructions +------------------------- + +If a #BR is generated due to a bounds violation caused by MPX. +We need to decode MPX instructions to get violation address and +set this address into extended struct siginfo. + +The _sigfault feild of struct siginfo is extended as follow: + +87 /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */ +88 struct { +89 void __user *_addr; /* faulting insn/memory ref. */ +90 #ifdef __ARCH_SI_TRAPNO +91 int _trapno; /* TRAP # which caused the signal */ +92 #endif +93 short _addr_lsb; /* LSB of the reported address */ +94 struct { +95 void __user *_lower; +96 void __user *_upper; +97 } _addr_bnd; +98 } _sigfault; + +The '_addr' field refers to violation address, and new '_addr_and' +field refers to the upper/lower bounds when a #BR is caused. + +Glibc will be also updated to support this new siginfo. So user +can get violation address and bounds when bounds violations occur. + +Cleanup unused bounds tables +---------------------------- + +When a BNDSTX instruction attempts to save bounds to a bounds directory +entry marked as invalid, a #BR is generated. This is an indication that +no bounds table exists for this entry. In this case the fault handler +will allocate a new bounds table on demand. + +Since the kernel allocated those tables on-demand without userspace +knowledge, it is also responsible for freeing them when the associated +mappings go away. + +Here, the solution for this issue is to hook do_munmap() to check +whether one process is MPX enabled. If yes, those bounds tables covered +in the virtual address region which is being unmapped will be freed also. + +Adding new prctl commands +------------------------- + +Two new prctl commands are added to enable and disable MPX bounds tables +management in kernel. + +155 #define PR_MPX_ENABLE_MANAGEMENT 43 +156 #define PR_MPX_DISABLE_MANAGEMENT 44 + +Runtime library in userspace is responsible for allocation of bounds +directory. So kernel have to use XSAVE instruction to get the base +of bounds directory from BNDCFG register. + +But XSAVE is expected to be very expensive. In order to do performance +optimization, we have to get the base of bounds directory and save it +into struct mm_struct to be used in future during PR_MPX_ENABLE_MANAGEMENT +command execution. + + +4. Special rules +================ + +1) If userspace is requesting help from the kernel to do the management +of bounds tables, it may not create or modify entries in the bounds directory. + +Certainly users can allocate bounds tables and forcibly point the bounds +directory at them through XSAVE instruction, and then set valid bit +of bounds entry to have this entry valid. But, the kernel will decline +to assist in managing these tables. + +2) Userspace may not take multiple bounds directory entries and point +them at the same bounds table. + +This is allowed architecturally. See more information "Intel(R) Architecture +Instruction Set Extensions Programming Reference" (9.3.4). + +However, if users did this, the kernel might be fooled in to unmaping an +in-use bounds table since it does not recognize sharing.