2008-10-22 22:26:29 -07:00
|
|
|
#ifndef _ASM_X86_MMU_CONTEXT_H
|
|
|
|
|
#define _ASM_X86_MMU_CONTEXT_H
|
2008-06-25 00:19:07 -04:00
|
|
|
|
|
|
|
|
#include <asm/desc.h>
|
2011-07-26 16:09:06 -07:00
|
|
|
#include <linux/atomic.h>
|
2014-07-31 08:40:59 -07:00
|
|
|
#include <linux/mm_types.h>
|
|
|
|
|
|
|
|
|
|
#include <trace/events/tlb.h>
|
|
|
|
|
|
2008-06-25 00:19:07 -04:00
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
|
#include <asm/tlbflush.h>
|
|
|
|
|
#include <asm/paravirt.h>
|
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.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 07:18:29 -08:00
|
|
|
#include <asm/mpx.h>
|
2018-07-14 02:32:07 -07:00
|
|
|
|
|
|
|
|
extern atomic64_t last_mm_ctx_id;
|
|
|
|
|
|
2008-06-25 00:19:07 -04:00
|
|
|
#ifndef CONFIG_PARAVIRT
|
|
|
|
|
static inline void paravirt_activate_mm(struct mm_struct *prev,
|
|
|
|
|
struct mm_struct *next)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
#endif /* !CONFIG_PARAVIRT */
|
|
|
|
|
|
2014-10-24 15:58:12 -07:00
|
|
|
#ifdef CONFIG_PERF_EVENTS
|
2014-10-24 15:58:13 -07:00
|
|
|
extern struct static_key rdpmc_always_available;
|
|
|
|
|
|
2014-10-24 15:58:12 -07:00
|
|
|
static inline void load_mm_cr4(struct mm_struct *mm)
|
|
|
|
|
{
|
2015-07-09 19:23:38 +02:00
|
|
|
if (static_key_false(&rdpmc_always_available) ||
|
2014-10-24 15:58:13 -07:00
|
|
|
atomic_read(&mm->context.perf_rdpmc_allowed))
|
2014-10-24 15:58:12 -07:00
|
|
|
cr4_set_bits(X86_CR4_PCE);
|
|
|
|
|
else
|
|
|
|
|
cr4_clear_bits(X86_CR4_PCE);
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
static inline void load_mm_cr4(struct mm_struct *mm) {}
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-07-30 14:31:34 -07:00
|
|
|
#ifdef CONFIG_MODIFY_LDT_SYSCALL
|
2015-07-30 14:31:32 -07:00
|
|
|
/*
|
|
|
|
|
* ldt_structs can be allocated, used, and freed, but they are never
|
|
|
|
|
* modified while live.
|
|
|
|
|
*/
|
|
|
|
|
struct ldt_struct {
|
|
|
|
|
/*
|
|
|
|
|
* Xen requires page-aligned LDTs with special permissions. This is
|
|
|
|
|
* needed to prevent us from installing evil descriptors such as
|
|
|
|
|
* call gates. On native, we could merge the ldt_struct and LDT
|
|
|
|
|
* allocations, but it's not worth trying to optimize.
|
|
|
|
|
*/
|
|
|
|
|
struct desc_struct *entries;
|
|
|
|
|
int size;
|
|
|
|
|
};
|
|
|
|
|
|
2015-07-30 14:31:34 -07:00
|
|
|
/*
|
|
|
|
|
* Used for LDT copy/destruction.
|
|
|
|
|
*/
|
2018-07-14 02:31:57 -07:00
|
|
|
int init_new_context_ldt(struct task_struct *tsk, struct mm_struct *mm);
|
|
|
|
|
void destroy_context_ldt(struct mm_struct *mm);
|
2015-07-30 14:31:34 -07:00
|
|
|
#else /* CONFIG_MODIFY_LDT_SYSCALL */
|
2018-07-14 02:31:57 -07:00
|
|
|
static inline int init_new_context_ldt(struct task_struct *tsk,
|
|
|
|
|
struct mm_struct *mm)
|
2015-07-30 14:31:34 -07:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2018-07-14 02:31:57 -07:00
|
|
|
static inline void destroy_context_ldt(struct mm_struct *mm) {}
|
2015-07-30 14:31:34 -07:00
|
|
|
#endif
|
|
|
|
|
|
2015-07-30 14:31:32 -07:00
|
|
|
static inline void load_mm_ldt(struct mm_struct *mm)
|
|
|
|
|
{
|
2015-07-30 14:31:34 -07:00
|
|
|
#ifdef CONFIG_MODIFY_LDT_SYSCALL
|
2015-07-30 14:31:32 -07:00
|
|
|
struct ldt_struct *ldt;
|
|
|
|
|
|
|
|
|
|
/* lockless_dereference synchronizes with smp_store_release */
|
|
|
|
|
ldt = lockless_dereference(mm->context.ldt);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Any change to mm->context.ldt is followed by an IPI to all
|
|
|
|
|
* CPUs with the mm active. The LDT will not be freed until
|
|
|
|
|
* after the IPI is handled by all such CPUs. This means that,
|
|
|
|
|
* if the ldt_struct changes before we return, the values we see
|
|
|
|
|
* will be safe, and the new values will be loaded before we run
|
|
|
|
|
* any user code.
|
|
|
|
|
*
|
|
|
|
|
* NB: don't try to convert this to use RCU without extreme care.
|
|
|
|
|
* We would still need IRQs off, because we don't want to change
|
|
|
|
|
* the local LDT after an IPI loaded a newer value than the one
|
|
|
|
|
* that we can see.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (unlikely(ldt))
|
|
|
|
|
set_ldt(ldt->entries, ldt->size);
|
|
|
|
|
else
|
|
|
|
|
clear_LDT();
|
2015-07-30 14:31:34 -07:00
|
|
|
#else
|
|
|
|
|
clear_LDT();
|
|
|
|
|
#endif
|
2015-07-30 14:31:32 -07:00
|
|
|
|
|
|
|
|
DEBUG_LOCKS_WARN_ON(preemptible());
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-21 17:26:06 +09:00
|
|
|
static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
|
|
|
|
|
{
|
2012-05-11 15:35:27 +08:00
|
|
|
if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
|
|
|
|
|
this_cpu_write(cpu_tlbstate.state, TLBSTATE_LAZY);
|
2009-01-21 17:26:06 +09:00
|
|
|
}
|
|
|
|
|
|
2018-07-14 02:31:57 -07:00
|
|
|
static inline int init_new_context(struct task_struct *tsk,
|
|
|
|
|
struct mm_struct *mm)
|
|
|
|
|
{
|
2018-07-14 02:32:07 -07:00
|
|
|
mm->context.ctx_id = atomic64_inc_return(&last_mm_ctx_id);
|
x86/mm: Fix use-after-free of ldt_struct
commit ccd5b3235180eef3cfec337df1c8554ab151b5cc upstream.
The following commit:
39a0526fb3f7 ("x86/mm: Factor out LDT init from context init")
renamed init_new_context() to init_new_context_ldt() and added a new
init_new_context() which calls init_new_context_ldt(). However, the
error code of init_new_context_ldt() was ignored. Consequently, if a
memory allocation in alloc_ldt_struct() failed during a fork(), the
->context.ldt of the new task remained the same as that of the old task
(due to the memcpy() in dup_mm()). ldt_struct's are not intended to be
shared, so a use-after-free occurred after one task exited.
Fix the bug by making init_new_context() pass through the error code of
init_new_context_ldt().
This bug was found by syzkaller, which encountered the following splat:
BUG: KASAN: use-after-free in free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
Read of size 4 at addr ffff88006d2cb7c8 by task kworker/u9:0/3710
CPU: 1 PID: 3710 Comm: kworker/u9:0 Not tainted 4.13.0-rc4-next-20170811 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:52
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x24e/0x340 mm/kasan/report.c:409
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
free_ldt_struct.part.2+0x10a/0x150 arch/x86/kernel/ldt.c:116
free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
__mmdrop+0xe9/0x530 kernel/fork.c:889
mmdrop include/linux/sched/mm.h:42 [inline]
exec_mmap fs/exec.c:1061 [inline]
flush_old_exec+0x173c/0x1ff0 fs/exec.c:1291
load_elf_binary+0x81f/0x4ba0 fs/binfmt_elf.c:855
search_binary_handler+0x142/0x6b0 fs/exec.c:1652
exec_binprm fs/exec.c:1694 [inline]
do_execveat_common.isra.33+0x1746/0x22e0 fs/exec.c:1816
do_execve+0x31/0x40 fs/exec.c:1860
call_usermodehelper_exec_async+0x457/0x8f0 kernel/umh.c:100
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Allocated by task 3700:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3627
kmalloc include/linux/slab.h:493 [inline]
alloc_ldt_struct+0x52/0x140 arch/x86/kernel/ldt.c:67
write_ldt+0x7b7/0xab0 arch/x86/kernel/ldt.c:277
sys_modify_ldt+0x1ef/0x240 arch/x86/kernel/ldt.c:307
entry_SYSCALL_64_fastpath+0x1f/0xbe
Freed by task 3700:
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:447
set_track mm/kasan/kasan.c:459 [inline]
kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
__cache_free mm/slab.c:3503 [inline]
kfree+0xca/0x250 mm/slab.c:3820
free_ldt_struct.part.2+0xdd/0x150 arch/x86/kernel/ldt.c:121
free_ldt_struct arch/x86/kernel/ldt.c:173 [inline]
destroy_context_ldt+0x60/0x80 arch/x86/kernel/ldt.c:171
destroy_context arch/x86/include/asm/mmu_context.h:157 [inline]
__mmdrop+0xe9/0x530 kernel/fork.c:889
mmdrop include/linux/sched/mm.h:42 [inline]
__mmput kernel/fork.c:916 [inline]
mmput+0x541/0x6e0 kernel/fork.c:927
copy_process.part.36+0x22e1/0x4af0 kernel/fork.c:1931
copy_process kernel/fork.c:1546 [inline]
_do_fork+0x1ef/0xfb0 kernel/fork.c:2025
SYSC_clone kernel/fork.c:2135 [inline]
SyS_clone+0x37/0x50 kernel/fork.c:2129
do_syscall_64+0x26c/0x8c0 arch/x86/entry/common.c:287
return_from_SYSCALL_64+0x0/0x7a
Here is a C reproducer:
#include <asm/ldt.h>
#include <pthread.h>
#include <signal.h>
#include <stdlib.h>
#include <sys/syscall.h>
#include <sys/wait.h>
#include <unistd.h>
static void *fork_thread(void *_arg)
{
fork();
}
int main(void)
{
struct user_desc desc = { .entry_number = 8191 };
syscall(__NR_modify_ldt, 1, &desc, sizeof(desc));
for (;;) {
if (fork() == 0) {
pthread_t t;
srand(getpid());
pthread_create(&t, NULL, fork_thread, NULL);
usleep(rand() % 10000);
syscall(__NR_exit_group, 0);
}
wait(NULL);
}
}
Note: the reproducer takes advantage of the fact that alloc_ldt_struct()
may use vmalloc() to allocate a large ->entries array, and after
commit:
5d17a73a2ebe ("vmalloc: back off when the current task is killed")
it is possible for userspace to fail a task's vmalloc() by
sending a fatal signal, e.g. via exit_group(). It would be more
difficult to reproduce this bug on kernels without that commit.
This bug only affected kernels with CONFIG_MODIFY_LDT_SYSCALL=y.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: <stable@vger.kernel.org> [v4.6+]
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Fixes: 39a0526fb3f7 ("x86/mm: Factor out LDT init from context init")
Link: http://lkml.kernel.org/r/20170824175029.76040-1-ebiggers3@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-24 10:50:29 -07:00
|
|
|
return init_new_context_ldt(tsk, mm);
|
2018-07-14 02:31:57 -07:00
|
|
|
}
|
|
|
|
|
static inline void destroy_context(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
destroy_context_ldt(mm);
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-26 09:39:08 -07:00
|
|
|
extern void switch_mm(struct mm_struct *prev, struct mm_struct *next,
|
|
|
|
|
struct task_struct *tsk);
|
2009-01-21 17:26:06 +09:00
|
|
|
|
2016-04-26 09:39:09 -07:00
|
|
|
extern void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
|
|
|
|
|
struct task_struct *tsk);
|
|
|
|
|
#define switch_mm_irqs_off switch_mm_irqs_off
|
2008-06-25 00:19:07 -04:00
|
|
|
|
|
|
|
|
#define activate_mm(prev, next) \
|
|
|
|
|
do { \
|
|
|
|
|
paravirt_activate_mm((prev), (next)); \
|
|
|
|
|
switch_mm((prev), (next), NULL); \
|
|
|
|
|
} while (0);
|
|
|
|
|
|
2009-01-21 17:26:06 +09:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
|
#define deactivate_mm(tsk, mm) \
|
|
|
|
|
do { \
|
2009-02-09 22:17:40 +09:00
|
|
|
lazy_load_gs(0); \
|
2009-01-21 17:26:06 +09:00
|
|
|
} while (0)
|
|
|
|
|
#else
|
|
|
|
|
#define deactivate_mm(tsk, mm) \
|
|
|
|
|
do { \
|
|
|
|
|
load_gs_index(0); \
|
|
|
|
|
loadsegment(fs, 0); \
|
|
|
|
|
} while (0)
|
|
|
|
|
#endif
|
2008-06-25 00:19:07 -04:00
|
|
|
|
2014-11-18 10:23:49 -08:00
|
|
|
static inline void arch_dup_mmap(struct mm_struct *oldmm,
|
|
|
|
|
struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
paravirt_arch_dup_mmap(oldmm, mm);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void arch_exit_mmap(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
paravirt_arch_exit_mmap(mm);
|
|
|
|
|
}
|
|
|
|
|
|
2015-06-07 11:37:04 -07:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
|
static inline bool is_64bit_mm(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
return !config_enabled(CONFIG_IA32_EMULATION) ||
|
|
|
|
|
!(mm->context.ia32_compat == TIF_IA32);
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
static inline bool is_64bit_mm(struct mm_struct *mm)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
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.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 07:18:29 -08:00
|
|
|
static inline void arch_bprm_mm_init(struct mm_struct *mm,
|
|
|
|
|
struct vm_area_struct *vma)
|
|
|
|
|
{
|
|
|
|
|
mpx_mm_init(mm);
|
|
|
|
|
}
|
|
|
|
|
|
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.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151831.E4531C4A@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 07:18:31 -08:00
|
|
|
static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
|
|
|
|
|
unsigned long start, unsigned long end)
|
|
|
|
|
{
|
2015-01-08 14:30:21 -08:00
|
|
|
/*
|
|
|
|
|
* mpx_notify_unmap() goes and reads a rarely-hot
|
|
|
|
|
* cacheline in the mm_struct. That can be expensive
|
|
|
|
|
* enough to be seen in profiles.
|
|
|
|
|
*
|
|
|
|
|
* The mpx_notify_unmap() call and its contents have been
|
|
|
|
|
* observed to affect munmap() performance on hardware
|
|
|
|
|
* where MPX is not present.
|
|
|
|
|
*
|
|
|
|
|
* The unlikely() optimizes for the fast case: no MPX
|
|
|
|
|
* in the CPU, or no MPX use in the process. Even if
|
|
|
|
|
* we get this wrong (in the unlikely event that MPX
|
|
|
|
|
* is widely enabled on some system) the overhead of
|
|
|
|
|
* MPX itself (reading bounds tables) is expected to
|
|
|
|
|
* overwhelm the overhead of getting this unlikely()
|
|
|
|
|
* consistently wrong.
|
|
|
|
|
*/
|
|
|
|
|
if (unlikely(cpu_feature_enabled(X86_FEATURE_MPX)))
|
|
|
|
|
mpx_notify_unmap(mm, vma, start, end);
|
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.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151831.E4531C4A@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 07:18:31 -08:00
|
|
|
}
|
|
|
|
|
|
2008-10-22 22:26:29 -07:00
|
|
|
#endif /* _ASM_X86_MMU_CONTEXT_H */
|
