2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
2008-07-02 07:29:44 +08:00
|
|
|
* Copyright (C) 2000, 2001, 2002 Andi Kleen, SuSE Labs
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Pentium III FXSR, SSE support
|
|
|
|
* Gareth Hughes <gareth@valinux.com>, May 2000
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2008-10-04 05:17:11 +08:00
|
|
|
* Handle hardware traps and faults.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2012-05-22 10:50:07 +08:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2013-02-24 07:23:25 +08:00
|
|
|
#include <linux/context_tracking.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/kallsyms.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/kprobes.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/kdebug.h>
|
2010-05-21 10:04:25 +08:00
|
|
|
#include <linux/kgdb.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/kernel.h>
|
2016-07-14 08:18:56 +08:00
|
|
|
#include <linux/export.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/ptrace.h>
|
uprobes/x86: Fix the wrong ->si_addr when xol triggers a trap
If the probed insn triggers a trap, ->si_addr = regs->ip is technically
correct, but this is not what the signal handler wants; we need to pass
the address of the probed insn, not the address of xol slot.
Add the new arch-agnostic helper, uprobe_get_trap_addr(), and change
fill_trap_info() and math_error() to use it. !CONFIG_UPROBES case in
uprobes.h uses a macro to avoid include hell and ensure that it can be
compiled even if an architecture doesn't define instruction_pointer().
Test-case:
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
extern void probe_div(void);
void sigh(int sig, siginfo_t *info, void *c)
{
int passed = (info->si_addr == probe_div);
printf(passed ? "PASS\n" : "FAIL\n");
_exit(!passed);
}
int main(void)
{
struct sigaction sa = {
.sa_sigaction = sigh,
.sa_flags = SA_SIGINFO,
};
sigaction(SIGFPE, &sa, NULL);
asm (
"xor %ecx,%ecx\n"
".globl probe_div; probe_div:\n"
"idiv %ecx\n"
);
return 0;
}
it fails if probe_div() is probed.
Note: show_unhandled_signals users should probably use this helper too,
but we need to cleanup them first.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-05-13 00:24:45 +08:00
|
|
|
#include <linux/uprobes.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/string.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/delay.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/errno.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/kexec.h>
|
|
|
|
#include <linux/sched.h>
|
2017-02-09 01:51:37 +08:00
|
|
|
#include <linux/sched/task_stack.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/timer.h>
|
|
|
|
#include <linux/init.h>
|
2006-12-08 18:36:21 +08:00
|
|
|
#include <linux/bug.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/nmi.h>
|
|
|
|
#include <linux/mm.h>
|
2008-10-04 05:17:11 +08:00
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/io.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-07-19 16:49:46 +08:00
|
|
|
#if defined(CONFIG_EDAC)
|
|
|
|
#include <linux/edac.h>
|
|
|
|
#endif
|
|
|
|
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <asm/stacktrace.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/debugreg.h>
|
2011-07-27 07:09:06 +08:00
|
|
|
#include <linux/atomic.h>
|
2016-04-27 03:23:24 +08:00
|
|
|
#include <asm/text-patching.h>
|
2011-08-16 21:57:10 +08:00
|
|
|
#include <asm/ftrace.h>
|
2008-10-04 05:17:11 +08:00
|
|
|
#include <asm/traps.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/desc.h>
|
2015-04-24 08:54:44 +08:00
|
|
|
#include <asm/fpu/internal.h>
|
2017-12-21 01:28:54 +08:00
|
|
|
#include <asm/cpu_entry_area.h>
|
2009-06-15 16:22:15 +08:00
|
|
|
#include <asm/mce.h>
|
2013-04-11 03:24:22 +08:00
|
|
|
#include <asm/fixmap.h>
|
2009-01-29 02:34:09 +08:00
|
|
|
#include <asm/mach_traps.h>
|
2013-07-23 16:09:28 +08:00
|
|
|
#include <asm/alternative.h>
|
2015-06-08 02:37:01 +08:00
|
|
|
#include <asm/fpu/xstate.h>
|
2015-06-08 02:37:03 +08:00
|
|
|
#include <asm/trace/mpx.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 23:18:29 +08:00
|
|
|
#include <asm/mpx.h>
|
2015-07-29 13:41:21 +08:00
|
|
|
#include <asm/vm86.h>
|
2017-11-06 10:27:55 +08:00
|
|
|
#include <asm/umip.h>
|
2008-10-04 05:17:11 +08:00
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
2009-08-20 16:35:46 +08:00
|
|
|
#include <asm/x86_init.h>
|
2008-10-04 04:00:39 +08:00
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/proto.h>
|
|
|
|
#else
|
2008-10-04 05:17:11 +08:00
|
|
|
#include <asm/processor-flags.h>
|
2009-02-23 07:34:39 +08:00
|
|
|
#include <asm/setup.h>
|
2015-06-08 14:42:03 +08:00
|
|
|
#include <asm/proto.h>
|
2008-10-04 04:00:39 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-09-14 05:29:26 +08:00
|
|
|
DECLARE_BITMAP(system_vectors, NR_VECTORS);
|
2008-12-20 07:23:44 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
static inline void cond_local_irq_enable(struct pt_regs *regs)
|
2008-09-10 03:55:55 +08:00
|
|
|
{
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
local_irq_enable();
|
|
|
|
}
|
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
static inline void cond_local_irq_disable(struct pt_regs *regs)
|
2008-10-01 00:41:37 +08:00
|
|
|
{
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
local_irq_disable();
|
|
|
|
}
|
|
|
|
|
2016-05-25 06:54:04 +08:00
|
|
|
/*
|
|
|
|
* In IST context, we explicitly disable preemption. This serves two
|
|
|
|
* purposes: it makes it much less likely that we would accidentally
|
|
|
|
* schedule in IST context and it will force a warning if we somehow
|
|
|
|
* manage to schedule by accident.
|
|
|
|
*/
|
2015-07-04 03:44:32 +08:00
|
|
|
void ist_enter(struct pt_regs *regs)
|
2014-11-20 09:41:09 +08:00
|
|
|
{
|
2015-03-19 09:33:33 +08:00
|
|
|
if (user_mode(regs)) {
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2014-11-20 09:41:09 +08:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We might have interrupted pretty much anything. In
|
|
|
|
* fact, if we're a machine check, we can even interrupt
|
|
|
|
* NMI processing. We don't want in_nmi() to return true,
|
|
|
|
* but we need to notify RCU.
|
|
|
|
*/
|
|
|
|
rcu_nmi_enter();
|
|
|
|
}
|
2015-01-31 20:53:53 +08:00
|
|
|
|
2016-05-25 06:54:04 +08:00
|
|
|
preempt_disable();
|
2015-01-31 20:53:53 +08:00
|
|
|
|
|
|
|
/* This code is a bit fragile. Test it. */
|
2015-06-19 06:50:02 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "ist_enter didn't work");
|
2014-11-20 09:41:09 +08:00
|
|
|
}
|
2019-02-13 00:12:15 +08:00
|
|
|
NOKPROBE_SYMBOL(ist_enter);
|
2014-11-20 09:41:09 +08:00
|
|
|
|
2015-07-04 03:44:32 +08:00
|
|
|
void ist_exit(struct pt_regs *regs)
|
2014-11-20 09:41:09 +08:00
|
|
|
{
|
2016-05-25 06:54:04 +08:00
|
|
|
preempt_enable_no_resched();
|
2014-11-20 09:41:09 +08:00
|
|
|
|
2015-07-04 03:44:32 +08:00
|
|
|
if (!user_mode(regs))
|
2014-11-20 09:41:09 +08:00
|
|
|
rcu_nmi_exit();
|
|
|
|
}
|
|
|
|
|
2014-11-20 09:59:41 +08:00
|
|
|
/**
|
|
|
|
* ist_begin_non_atomic() - begin a non-atomic section in an IST exception
|
|
|
|
* @regs: regs passed to the IST exception handler
|
|
|
|
*
|
|
|
|
* IST exception handlers normally cannot schedule. As a special
|
|
|
|
* exception, if the exception interrupted userspace code (i.e.
|
2015-03-19 09:33:33 +08:00
|
|
|
* user_mode(regs) would return true) and the exception was not
|
2014-11-20 09:59:41 +08:00
|
|
|
* a double fault, it can be safe to schedule. ist_begin_non_atomic()
|
|
|
|
* begins a non-atomic section within an ist_enter()/ist_exit() region.
|
|
|
|
* Callers are responsible for enabling interrupts themselves inside
|
2015-07-04 03:44:32 +08:00
|
|
|
* the non-atomic section, and callers must call ist_end_non_atomic()
|
2014-11-20 09:59:41 +08:00
|
|
|
* before ist_exit().
|
|
|
|
*/
|
|
|
|
void ist_begin_non_atomic(struct pt_regs *regs)
|
|
|
|
{
|
2015-03-19 09:33:33 +08:00
|
|
|
BUG_ON(!user_mode(regs));
|
2014-11-20 09:59:41 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Sanity check: we need to be on the normal thread stack. This
|
|
|
|
* will catch asm bugs and any attempt to use ist_preempt_enable
|
|
|
|
* from double_fault.
|
|
|
|
*/
|
2017-11-02 15:59:17 +08:00
|
|
|
BUG_ON(!on_thread_stack());
|
2014-11-20 09:59:41 +08:00
|
|
|
|
2016-05-25 06:54:04 +08:00
|
|
|
preempt_enable_no_resched();
|
2014-11-20 09:59:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ist_end_non_atomic() - begin a non-atomic section in an IST exception
|
|
|
|
*
|
|
|
|
* Ends a non-atomic section started with ist_begin_non_atomic().
|
|
|
|
*/
|
|
|
|
void ist_end_non_atomic(void)
|
|
|
|
{
|
2016-05-25 06:54:04 +08:00
|
|
|
preempt_disable();
|
2014-11-20 09:59:41 +08:00
|
|
|
}
|
|
|
|
|
2017-02-02 21:43:51 +08:00
|
|
|
int is_valid_bugaddr(unsigned long addr)
|
|
|
|
{
|
|
|
|
unsigned short ud;
|
|
|
|
|
|
|
|
if (addr < TASK_SIZE_MAX)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (probe_kernel_address((unsigned short *)addr, ud))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return ud == INSN_UD0 || ud == INSN_UD2;
|
|
|
|
}
|
|
|
|
|
2017-06-12 19:52:46 +08:00
|
|
|
int fixup_bug(struct pt_regs *regs, int trapnr)
|
2017-02-02 21:43:51 +08:00
|
|
|
{
|
|
|
|
if (trapnr != X86_TRAP_UD)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
switch (report_bug(regs->ip, regs)) {
|
|
|
|
case BUG_TRAP_TYPE_NONE:
|
|
|
|
case BUG_TRAP_TYPE_BUG:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case BUG_TRAP_TYPE_WARN:
|
2018-02-09 20:16:59 +08:00
|
|
|
regs->ip += LEN_UD2;
|
2017-02-02 21:43:51 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
static nokprobe_inline int
|
2017-08-05 03:01:50 +08:00
|
|
|
do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
|
2012-09-25 20:51:19 +08:00
|
|
|
struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2015-03-19 09:33:35 +08:00
|
|
|
if (v8086_mode(regs)) {
|
2008-09-26 20:03:08 +08:00
|
|
|
/*
|
2012-09-25 20:51:19 +08:00
|
|
|
* Traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
|
2008-09-26 20:03:08 +08:00
|
|
|
* On nmi (interrupt 2), do_trap should not be called.
|
|
|
|
*/
|
2012-09-25 20:51:19 +08:00
|
|
|
if (trapnr < X86_TRAP_UD) {
|
|
|
|
if (!handle_vm86_trap((struct kernel_vm86_regs *) regs,
|
|
|
|
error_code, trapnr))
|
|
|
|
return 0;
|
|
|
|
}
|
2017-08-05 03:01:50 +08:00
|
|
|
} else if (!user_mode(regs)) {
|
2018-08-29 04:14:19 +08:00
|
|
|
if (fixup_exception(regs, trapnr, error_code, 0))
|
2017-02-02 21:43:51 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
|
|
|
tsk->thread.trap_nr = trapnr;
|
|
|
|
die(str, regs, error_code);
|
2012-09-25 20:51:19 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-02-26 18:15:50 +08:00
|
|
|
/*
|
2012-03-12 17:25:55 +08:00
|
|
|
* We want error_code and trap_nr set for userspace faults and
|
2008-02-26 18:15:50 +08:00
|
|
|
* kernelspace faults which result in die(), but not
|
|
|
|
* kernelspace faults which are fixed up. die() gives the
|
|
|
|
* process no chance to handle the signal and notice the
|
|
|
|
* kernel fault information, so that won't result in polluting
|
|
|
|
* the information about previously queued, but not yet
|
|
|
|
* delivered, faults. See also do_general_protection below.
|
|
|
|
*/
|
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 17:25:55 +08:00
|
|
|
tsk->thread.trap_nr = trapnr;
|
2007-05-03 01:27:05 +08:00
|
|
|
|
2012-09-25 20:51:19 +08:00
|
|
|
return -1;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-08-04 03:34:24 +08:00
|
|
|
static void show_signal(struct task_struct *tsk, int signr,
|
|
|
|
const char *type, const char *desc,
|
|
|
|
struct pt_regs *regs, long error_code)
|
|
|
|
{
|
2008-10-04 04:00:39 +08:00
|
|
|
if (show_unhandled_signals && unhandled_signal(tsk, signr) &&
|
|
|
|
printk_ratelimit()) {
|
2017-08-04 03:34:24 +08:00
|
|
|
pr_info("%s[%d] %s%s ip:%lx sp:%lx error:%lx",
|
|
|
|
tsk->comm, task_pid_nr(tsk), type, desc,
|
2012-05-22 10:50:07 +08:00
|
|
|
regs->ip, regs->sp, error_code);
|
2017-04-07 20:09:04 +08:00
|
|
|
print_vma_addr(KERN_CONT " in ", regs->ip);
|
2012-05-22 10:50:07 +08:00
|
|
|
pr_cont("\n");
|
2008-10-04 04:00:39 +08:00
|
|
|
}
|
2017-08-04 03:34:24 +08:00
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
static void
|
2012-09-25 20:51:19 +08:00
|
|
|
do_trap(int trapnr, int signr, char *str, struct pt_regs *regs,
|
2018-04-17 03:29:39 +08:00
|
|
|
long error_code, int sicode, void __user *addr)
|
2012-09-25 20:51:19 +08:00
|
|
|
{
|
|
|
|
struct task_struct *tsk = current;
|
|
|
|
|
|
|
|
|
|
|
|
if (!do_trap_no_signal(tsk, trapnr, str, regs, error_code))
|
|
|
|
return;
|
2007-05-03 01:27:05 +08:00
|
|
|
|
2017-08-04 03:34:24 +08:00
|
|
|
show_signal(tsk, signr, "trap ", str, regs, error_code);
|
2008-10-04 04:00:39 +08:00
|
|
|
|
2018-04-17 03:29:39 +08:00
|
|
|
if (!sicode)
|
|
|
|
force_sig(signr, tsk);
|
|
|
|
else
|
|
|
|
force_sig_fault(signr, sicode, addr, tsk);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_trap);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-07 23:21:34 +08:00
|
|
|
static void do_error_trap(struct pt_regs *regs, long error_code, char *str,
|
2018-04-17 03:29:39 +08:00
|
|
|
unsigned long trapnr, int signr, int sicode, void __user *addr)
|
2014-05-07 23:21:34 +08:00
|
|
|
{
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2015-07-04 03:44:24 +08:00
|
|
|
|
2017-07-24 18:04:28 +08:00
|
|
|
/*
|
|
|
|
* WARN*()s end up here; fix them up before we call the
|
|
|
|
* notifier chain.
|
|
|
|
*/
|
|
|
|
if (!user_mode(regs) && fixup_bug(regs, trapnr))
|
|
|
|
return;
|
|
|
|
|
2014-05-07 23:21:34 +08:00
|
|
|
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
|
|
|
|
NOTIFY_STOP) {
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2018-04-17 03:29:39 +08:00
|
|
|
do_trap(trapnr, signr, str, regs, error_code, sicode, addr);
|
2014-05-07 23:21:34 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-17 03:29:39 +08:00
|
|
|
#define IP ((void __user *)uprobe_get_trap_addr(regs))
|
|
|
|
#define DO_ERROR(trapnr, signr, sicode, addr, str, name) \
|
|
|
|
dotraplinkage void do_##name(struct pt_regs *regs, long error_code) \
|
|
|
|
{ \
|
|
|
|
do_error_trap(regs, error_code, str, trapnr, signr, sicode, addr); \
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2018-04-17 03:29:39 +08:00
|
|
|
DO_ERROR(X86_TRAP_DE, SIGFPE, FPE_INTDIV, IP, "divide error", divide_error)
|
|
|
|
DO_ERROR(X86_TRAP_OF, SIGSEGV, 0, NULL, "overflow", overflow)
|
|
|
|
DO_ERROR(X86_TRAP_UD, SIGILL, ILL_ILLOPN, IP, "invalid opcode", invalid_op)
|
|
|
|
DO_ERROR(X86_TRAP_OLD_MF, SIGFPE, 0, NULL, "coprocessor segment overrun", coprocessor_segment_overrun)
|
|
|
|
DO_ERROR(X86_TRAP_TS, SIGSEGV, 0, NULL, "invalid TSS", invalid_TSS)
|
|
|
|
DO_ERROR(X86_TRAP_NP, SIGBUS, 0, NULL, "segment not present", segment_not_present)
|
|
|
|
DO_ERROR(X86_TRAP_SS, SIGBUS, 0, NULL, "stack segment", stack_segment)
|
|
|
|
DO_ERROR(X86_TRAP_AC, SIGBUS, BUS_ADRALN, NULL, "alignment check", alignment_check)
|
|
|
|
#undef IP
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-08-11 17:35:23 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
2016-08-31 08:27:57 +08:00
|
|
|
__visible void __noreturn handle_stack_overflow(const char *message,
|
|
|
|
struct pt_regs *regs,
|
|
|
|
unsigned long fault_address)
|
2016-08-11 17:35:23 +08:00
|
|
|
{
|
|
|
|
printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is %p..%p)\n",
|
|
|
|
(void *)fault_address, current->stack,
|
|
|
|
(char *)current->stack + THREAD_SIZE - 1);
|
|
|
|
die(message, regs, 0);
|
|
|
|
|
|
|
|
/* Be absolutely certain we don't return. */
|
2018-10-27 06:20:04 +08:00
|
|
|
panic("%s", message);
|
2016-08-11 17:35:23 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
/* Runs on IST stack */
|
|
|
|
dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code)
|
|
|
|
{
|
|
|
|
static const char str[] = "double fault";
|
|
|
|
struct task_struct *tsk = current;
|
2016-08-11 17:35:23 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
|
|
|
unsigned long cr2;
|
|
|
|
#endif
|
2008-10-04 04:00:39 +08:00
|
|
|
|
2014-11-23 10:00:31 +08:00
|
|
|
#ifdef CONFIG_X86_ESPFIX64
|
|
|
|
extern unsigned char native_irq_return_iret[];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If IRET takes a non-IST fault on the espfix64 stack, then we
|
2017-12-04 22:07:22 +08:00
|
|
|
* end up promoting it to a doublefault. In that case, take
|
|
|
|
* advantage of the fact that we're not using the normal (TSS.sp0)
|
|
|
|
* stack right now. We can write a fake #GP(0) frame at TSS.sp0
|
|
|
|
* and then modify our own IRET frame so that, when we return,
|
|
|
|
* we land directly at the #GP(0) vector with the stack already
|
|
|
|
* set up according to its expectations.
|
|
|
|
*
|
|
|
|
* The net result is that our #GP handler will think that we
|
|
|
|
* entered from usermode with the bad user context.
|
2014-11-20 09:41:09 +08:00
|
|
|
*
|
|
|
|
* No need for ist_enter here because we don't use RCU.
|
2014-11-23 10:00:31 +08:00
|
|
|
*/
|
2017-12-12 23:56:36 +08:00
|
|
|
if (((long)regs->sp >> P4D_SHIFT) == ESPFIX_PGD_ENTRY &&
|
2014-11-23 10:00:31 +08:00
|
|
|
regs->cs == __KERNEL_CS &&
|
|
|
|
regs->ip == (unsigned long)native_irq_return_iret)
|
|
|
|
{
|
2017-12-04 22:07:29 +08:00
|
|
|
struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
|
2014-11-23 10:00:31 +08:00
|
|
|
|
2017-12-04 22:07:22 +08:00
|
|
|
/*
|
|
|
|
* regs->sp points to the failing IRET frame on the
|
|
|
|
* ESPFIX64 stack. Copy it to the entry stack. This fills
|
|
|
|
* in gpregs->ss through gpregs->ip.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
memmove(&gpregs->ip, (void *)regs->sp, 5*8);
|
|
|
|
gpregs->orig_ax = 0; /* Missing (lost) #GP error code */
|
2014-11-23 10:00:31 +08:00
|
|
|
|
2017-12-04 22:07:22 +08:00
|
|
|
/*
|
|
|
|
* Adjust our frame so that we return straight to the #GP
|
|
|
|
* vector with the expected RSP value. This is safe because
|
|
|
|
* we won't enable interupts or schedule before we invoke
|
|
|
|
* general_protection, so nothing will clobber the stack
|
|
|
|
* frame we just set up.
|
2018-09-04 06:59:42 +08:00
|
|
|
*
|
|
|
|
* We will enter general_protection with kernel GSBASE,
|
|
|
|
* which is what the stub expects, given that the faulting
|
|
|
|
* RIP will be the IRET instruction.
|
2017-12-04 22:07:22 +08:00
|
|
|
*/
|
2014-11-23 10:00:31 +08:00
|
|
|
regs->ip = (unsigned long)general_protection;
|
2017-12-04 22:07:22 +08:00
|
|
|
regs->sp = (unsigned long)&gpregs->orig_ax;
|
2014-11-20 09:41:09 +08:00
|
|
|
|
2014-11-23 10:00:31 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-07-04 03:44:32 +08:00
|
|
|
ist_enter(regs);
|
2012-03-10 08:07:10 +08:00
|
|
|
notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_DF, SIGSEGV);
|
2008-10-04 04:00:39 +08:00
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 17:25:55 +08:00
|
|
|
tsk->thread.trap_nr = X86_TRAP_DF;
|
2008-10-04 04:00:39 +08:00
|
|
|
|
2016-08-11 17:35:23 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
|
|
|
/*
|
|
|
|
* If we overflow the stack into a guard page, the CPU will fail
|
|
|
|
* to deliver #PF and will send #DF instead. Similarly, if we
|
|
|
|
* take any non-IST exception while too close to the bottom of
|
|
|
|
* the stack, the processor will get a page fault while
|
|
|
|
* delivering the exception and will generate a double fault.
|
|
|
|
*
|
|
|
|
* According to the SDM (footnote in 6.15 under "Interrupt 14 -
|
|
|
|
* Page-Fault Exception (#PF):
|
|
|
|
*
|
|
|
|
* Processors update CR2 whenever a page fault is detected. If a
|
|
|
|
* second page fault occurs while an earlier page fault is being
|
2017-12-04 22:07:22 +08:00
|
|
|
* delivered, the faulting linear address of the second fault will
|
2016-08-11 17:35:23 +08:00
|
|
|
* overwrite the contents of CR2 (replacing the previous
|
|
|
|
* address). These updates to CR2 occur even if the page fault
|
|
|
|
* results in a double fault or occurs during the delivery of a
|
|
|
|
* double fault.
|
|
|
|
*
|
|
|
|
* The logic below has a small possibility of incorrectly diagnosing
|
|
|
|
* some errors as stack overflows. For example, if the IDT or GDT
|
|
|
|
* gets corrupted such that #GP delivery fails due to a bad descriptor
|
|
|
|
* causing #GP and we hit this condition while CR2 coincidentally
|
|
|
|
* points to the stack guard page, we'll think we overflowed the
|
|
|
|
* stack. Given that we're going to panic one way or another
|
|
|
|
* if this happens, this isn't necessarily worth fixing.
|
|
|
|
*
|
|
|
|
* If necessary, we could improve the test by only diagnosing
|
|
|
|
* a stack overflow if the saved RSP points within 47 bytes of
|
|
|
|
* the bottom of the stack: if RSP == tsk_stack + 48 and we
|
|
|
|
* take an exception, the stack is already aligned and there
|
|
|
|
* will be enough room SS, RSP, RFLAGS, CS, RIP, and a
|
|
|
|
* possible error code, so a stack overflow would *not* double
|
|
|
|
* fault. With any less space left, exception delivery could
|
|
|
|
* fail, and, as a practical matter, we've overflowed the
|
|
|
|
* stack even if the actual trigger for the double fault was
|
|
|
|
* something else.
|
|
|
|
*/
|
|
|
|
cr2 = read_cr2();
|
|
|
|
if ((unsigned long)task_stack_page(tsk) - 1 - cr2 < PAGE_SIZE)
|
|
|
|
handle_stack_overflow("kernel stack overflow (double-fault)", regs, cr2);
|
|
|
|
#endif
|
|
|
|
|
2013-05-09 18:02:29 +08:00
|
|
|
#ifdef CONFIG_DOUBLEFAULT
|
|
|
|
df_debug(regs, error_code);
|
|
|
|
#endif
|
2008-12-26 16:20:22 +08:00
|
|
|
/*
|
|
|
|
* This is always a kernel trap and never fixable (and thus must
|
|
|
|
* never return).
|
|
|
|
*/
|
2008-10-04 04:00:39 +08:00
|
|
|
for (;;)
|
|
|
|
die(str, regs, error_code);
|
|
|
|
}
|
|
|
|
#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 23:18:29 +08:00
|
|
|
dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
|
|
|
|
{
|
2015-09-03 07:31:29 +08:00
|
|
|
const struct mpx_bndcsr *bndcsr;
|
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 23:18:29 +08:00
|
|
|
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
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 23:18:29 +08:00
|
|
|
if (notify_die(DIE_TRAP, "bounds", regs, error_code,
|
|
|
|
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
|
2015-07-04 03:44:32 +08:00
|
|
|
return;
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
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 23:18:29 +08:00
|
|
|
|
2015-03-19 09:33:33 +08:00
|
|
|
if (!user_mode(regs))
|
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 23:18:29 +08:00
|
|
|
die("bounds", regs, error_code);
|
|
|
|
|
|
|
|
if (!cpu_feature_enabled(X86_FEATURE_MPX)) {
|
|
|
|
/* The exception is not from Intel MPX */
|
|
|
|
goto exit_trap;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to look at BNDSTATUS to resolve this exception.
|
2015-06-08 02:37:01 +08:00
|
|
|
* A NULL here might mean that it is in its 'init state',
|
|
|
|
* which is all zeros which indicates MPX was not
|
|
|
|
* responsible for the exception.
|
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 23:18:29 +08:00
|
|
|
*/
|
2019-04-04 00:41:40 +08:00
|
|
|
bndcsr = get_xsave_field_ptr(XFEATURE_BNDCSR);
|
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 23:18:29 +08:00
|
|
|
if (!bndcsr)
|
|
|
|
goto exit_trap;
|
|
|
|
|
2015-06-08 02:37:03 +08:00
|
|
|
trace_bounds_exception_mpx(bndcsr);
|
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 23:18:29 +08:00
|
|
|
/*
|
|
|
|
* The error code field of the BNDSTATUS register communicates status
|
|
|
|
* information of a bound range exception #BR or operation involving
|
|
|
|
* bound directory.
|
|
|
|
*/
|
|
|
|
switch (bndcsr->bndstatus & MPX_BNDSTA_ERROR_CODE) {
|
|
|
|
case 2: /* Bound directory has invalid entry. */
|
2015-06-08 02:37:02 +08:00
|
|
|
if (mpx_handle_bd_fault())
|
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 23:18:29 +08:00
|
|
|
goto exit_trap;
|
|
|
|
break; /* Success, it was handled */
|
|
|
|
case 1: /* Bound violation. */
|
2018-01-04 09:22:04 +08:00
|
|
|
{
|
2017-08-20 01:14:49 +08:00
|
|
|
struct task_struct *tsk = current;
|
2018-01-04 09:22:04 +08:00
|
|
|
struct mpx_fault_info mpx;
|
|
|
|
|
|
|
|
if (mpx_fault_info(&mpx, regs)) {
|
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 23:18:29 +08:00
|
|
|
/*
|
|
|
|
* We failed to decode the MPX instruction. Act as if
|
|
|
|
* the exception was not caused by MPX.
|
|
|
|
*/
|
|
|
|
goto exit_trap;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Success, we decoded the instruction and retrieved
|
2017-08-20 01:14:49 +08:00
|
|
|
* an 'mpx' containing the address being accessed
|
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 23:18:29 +08:00
|
|
|
* which caused the exception. This information
|
|
|
|
* allows and application to possibly handle the
|
|
|
|
* #BR exception itself.
|
|
|
|
*/
|
2017-08-20 01:14:49 +08:00
|
|
|
if (!do_trap_no_signal(tsk, X86_TRAP_BR, "bounds", regs,
|
|
|
|
error_code))
|
|
|
|
break;
|
|
|
|
|
|
|
|
show_signal(tsk, SIGSEGV, "trap ", "bounds", regs, error_code);
|
|
|
|
|
|
|
|
force_sig_bnderr(mpx.addr, mpx.lower, mpx.upper);
|
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 23:18:29 +08:00
|
|
|
break;
|
2018-01-04 09:22:04 +08:00
|
|
|
}
|
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 23:18:29 +08:00
|
|
|
case 0: /* No exception caused by Intel MPX operations. */
|
|
|
|
goto exit_trap;
|
|
|
|
default:
|
|
|
|
die("bounds", regs, error_code);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
2015-07-04 03:44:32 +08:00
|
|
|
|
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 23:18:29 +08:00
|
|
|
exit_trap:
|
|
|
|
/*
|
|
|
|
* This path out is for all the cases where we could not
|
|
|
|
* handle the exception in some way (like allocating a
|
|
|
|
* table or telling userspace about it. We will also end
|
|
|
|
* up here if the kernel has MPX turned off at compile
|
|
|
|
* time..
|
|
|
|
*/
|
2018-04-17 03:29:39 +08:00
|
|
|
do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, 0, NULL);
|
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 23:18:29 +08:00
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
dotraplinkage void
|
2008-07-02 07:32:04 +08:00
|
|
|
do_general_protection(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2017-08-04 03:34:24 +08:00
|
|
|
const char *desc = "general protection fault";
|
2008-07-02 07:32:04 +08:00
|
|
|
struct task_struct *tsk;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2008-09-10 03:56:07 +08:00
|
|
|
|
2017-11-06 10:27:55 +08:00
|
|
|
if (static_cpu_has(X86_FEATURE_UMIP)) {
|
|
|
|
if (user_mode(regs) && fixup_umip_exception(regs))
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-03-19 09:33:35 +08:00
|
|
|
if (v8086_mode(regs)) {
|
2012-09-25 03:05:52 +08:00
|
|
|
local_irq_enable();
|
|
|
|
handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
|
2015-07-04 03:44:32 +08:00
|
|
|
return;
|
2012-09-25 03:05:52 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-07-02 07:32:04 +08:00
|
|
|
tsk = current;
|
2015-03-29 17:02:34 +08:00
|
|
|
if (!user_mode(regs)) {
|
2018-08-29 04:14:19 +08:00
|
|
|
if (fixup_exception(regs, X86_TRAP_GP, error_code, 0))
|
2015-07-04 03:44:32 +08:00
|
|
|
return;
|
2012-09-25 03:05:52 +08:00
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
|
|
|
tsk->thread.trap_nr = X86_TRAP_GP;
|
2018-08-29 04:14:16 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* To be potentially processing a kprobe fault and to
|
|
|
|
* trust the result from kprobe_running(), we have to
|
|
|
|
* be non-preemptible.
|
|
|
|
*/
|
|
|
|
if (!preemptible() && kprobe_running() &&
|
|
|
|
kprobe_fault_handler(regs, X86_TRAP_GP))
|
|
|
|
return;
|
|
|
|
|
2017-08-04 03:34:24 +08:00
|
|
|
if (notify_die(DIE_GPF, desc, regs, error_code,
|
2012-07-12 02:26:35 +08:00
|
|
|
X86_TRAP_GP, SIGSEGV) != NOTIFY_STOP)
|
2017-08-04 03:34:24 +08:00
|
|
|
die(desc, regs, error_code);
|
2015-07-04 03:44:32 +08:00
|
|
|
return;
|
2012-09-25 03:05:52 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-07-02 07:32:04 +08:00
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 17:25:55 +08:00
|
|
|
tsk->thread.trap_nr = X86_TRAP_GP;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2017-08-04 03:34:24 +08:00
|
|
|
show_signal(tsk, SIGSEGV, "", desc, regs, error_code);
|
2007-07-22 17:12:28 +08:00
|
|
|
|
2017-08-08 23:55:19 +08:00
|
|
|
force_sig(SIGSEGV, tsk);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_general_protection);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2011-08-16 21:57:10 +08:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
2012-05-31 01:26:37 +08:00
|
|
|
/*
|
|
|
|
* ftrace must be first, everything else may cause a recursive crash.
|
|
|
|
* See note by declaration of modifying_ftrace_code in ftrace.c
|
|
|
|
*/
|
|
|
|
if (unlikely(atomic_read(&modifying_ftrace_code)) &&
|
|
|
|
ftrace_int3_handler(regs))
|
2011-08-16 21:57:10 +08:00
|
|
|
return;
|
|
|
|
#endif
|
2013-07-23 16:09:28 +08:00
|
|
|
if (poke_int3_handler(regs))
|
|
|
|
return;
|
|
|
|
|
2015-07-24 06:37:48 +08:00
|
|
|
/*
|
|
|
|
* Use ist_enter despite the fact that we don't use an IST stack.
|
|
|
|
* We can be called from a kprobe in non-CONTEXT_KERNEL kernel
|
|
|
|
* mode or even during context tracking state changes.
|
|
|
|
*
|
|
|
|
* This means that we can't schedule. That's okay.
|
|
|
|
*/
|
2015-07-04 03:44:32 +08:00
|
|
|
ist_enter(regs);
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2010-05-21 10:04:25 +08:00
|
|
|
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
|
2012-03-10 08:07:10 +08:00
|
|
|
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2010-05-21 10:04:25 +08:00
|
|
|
#endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
|
2011-10-25 22:21:59 +08:00
|
|
|
|
kprobes/x86: Call exception handlers directly from do_int3/do_debug
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler() and kprobe_debug_handler()(which was
formerly called post_kprobe_handler()) directly from
do_int3 and do_debug.
Currently kprobes uses notify_die() to hook the int3/debug
exceptoins. Since there is a locking code in notify_die,
the lockdep code can be invoked. And because the lockdep
involves printk() related things, theoretically, we need to
prohibit probing on such code, which means much longer blacklist
we'll have. Instead, hooking the int3/debug for kprobes before
notify_die() can avoid this problem.
Anyway, most of the int3 handlers in the kernel are already
called from do_int3 directly, e.g. ftrace_int3_handler,
poke_int3_handler, kgdb_ll_trap. Actually only
kprobe_exceptions_notify is on the notifier_call_chain.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Lebon <jlebon@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/20140417081733.26341.24423.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-04-17 16:17:33 +08:00
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_int3_handler(regs))
|
2014-06-14 14:47:12 +08:00
|
|
|
goto exit;
|
kprobes/x86: Call exception handlers directly from do_int3/do_debug
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler() and kprobe_debug_handler()(which was
formerly called post_kprobe_handler()) directly from
do_int3 and do_debug.
Currently kprobes uses notify_die() to hook the int3/debug
exceptoins. Since there is a locking code in notify_die,
the lockdep code can be invoked. And because the lockdep
involves printk() related things, theoretically, we need to
prohibit probing on such code, which means much longer blacklist
we'll have. Instead, hooking the int3/debug for kprobes before
notify_die() can avoid this problem.
Anyway, most of the int3 handlers in the kernel are already
called from do_int3 directly, e.g. ftrace_int3_handler,
poke_int3_handler, kgdb_ll_trap. Actually only
kprobe_exceptions_notify is on the notifier_call_chain.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Lebon <jlebon@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/20140417081733.26341.24423.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-04-17 16:17:33 +08:00
|
|
|
#endif
|
|
|
|
|
2012-03-10 08:07:10 +08:00
|
|
|
if (notify_die(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2018-04-17 03:29:39 +08:00
|
|
|
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, 0, NULL);
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2015-07-24 06:37:48 +08:00
|
|
|
|
2012-07-12 02:26:35 +08:00
|
|
|
exit:
|
2015-07-04 03:44:32 +08:00
|
|
|
ist_exit(regs);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_int3);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
2008-12-26 16:20:22 +08:00
|
|
|
/*
|
2017-12-04 22:07:23 +08:00
|
|
|
* Help handler running on a per-cpu (IST or entry trampoline) stack
|
|
|
|
* to switch to the normal thread stack if the interrupted code was in
|
|
|
|
* user mode. The actual stack switch is done in entry_64.S
|
2008-12-26 16:20:22 +08:00
|
|
|
*/
|
2014-11-25 09:39:06 +08:00
|
|
|
asmlinkage __visible notrace struct pt_regs *sync_regs(struct pt_regs *eregs)
|
2008-10-04 04:00:39 +08:00
|
|
|
{
|
2017-12-04 22:07:23 +08:00
|
|
|
struct pt_regs *regs = (struct pt_regs *)this_cpu_read(cpu_current_top_of_stack) - 1;
|
|
|
|
if (regs != eregs)
|
|
|
|
*regs = *eregs;
|
2008-10-04 04:00:39 +08:00
|
|
|
return regs;
|
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(sync_regs);
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
|
|
|
|
struct bad_iret_stack {
|
|
|
|
void *error_entry_ret;
|
|
|
|
struct pt_regs regs;
|
|
|
|
};
|
|
|
|
|
2014-11-25 09:39:06 +08:00
|
|
|
asmlinkage __visible notrace
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This is called from entry_64.S early in handling a fault
|
|
|
|
* caused by a bad iret to user mode. To handle the fault
|
2017-12-04 22:07:23 +08:00
|
|
|
* correctly, we want to move our stack frame to where it would
|
|
|
|
* be had we entered directly on the entry stack (rather than
|
|
|
|
* just below the IRET frame) and we want to pretend that the
|
|
|
|
* exception came from the IRET target.
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
*/
|
|
|
|
struct bad_iret_stack *new_stack =
|
2017-12-04 22:07:29 +08:00
|
|
|
(struct bad_iret_stack *)this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
|
|
|
|
/* Copy the IRET target to the new stack. */
|
|
|
|
memmove(&new_stack->regs.ip, (void *)s->regs.sp, 5*8);
|
|
|
|
|
|
|
|
/* Copy the remainder of the stack from the current stack. */
|
|
|
|
memmove(new_stack, s, offsetof(struct bad_iret_stack, regs.ip));
|
|
|
|
|
2015-03-19 09:33:33 +08:00
|
|
|
BUG_ON(!user_mode(&new_stack->regs));
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
return new_stack;
|
|
|
|
}
|
2014-11-25 09:39:06 +08:00
|
|
|
NOKPROBE_SYMBOL(fixup_bad_iret);
|
2008-10-04 04:00:39 +08:00
|
|
|
#endif
|
|
|
|
|
2016-03-10 11:00:30 +08:00
|
|
|
static bool is_sysenter_singlestep(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We don't try for precision here. If we're anywhere in the region of
|
|
|
|
* code that can be single-stepped in the SYSENTER entry path, then
|
|
|
|
* assume that this is a useless single-step trap due to SYSENTER
|
|
|
|
* being invoked with TF set. (We don't know in advance exactly
|
|
|
|
* which instructions will be hit because BTF could plausibly
|
|
|
|
* be set.)
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
return (regs->ip - (unsigned long)__begin_SYSENTER_singlestep_region) <
|
|
|
|
(unsigned long)__end_SYSENTER_singlestep_region -
|
|
|
|
(unsigned long)__begin_SYSENTER_singlestep_region;
|
|
|
|
#elif defined(CONFIG_IA32_EMULATION)
|
|
|
|
return (regs->ip - (unsigned long)entry_SYSENTER_compat) <
|
|
|
|
(unsigned long)__end_entry_SYSENTER_compat -
|
|
|
|
(unsigned long)entry_SYSENTER_compat;
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Our handling of the processor debug registers is non-trivial.
|
|
|
|
* We do not clear them on entry and exit from the kernel. Therefore
|
|
|
|
* it is possible to get a watchpoint trap here from inside the kernel.
|
|
|
|
* However, the code in ./ptrace.c has ensured that the user can
|
|
|
|
* only set watchpoints on userspace addresses. Therefore the in-kernel
|
|
|
|
* watchpoint trap can only occur in code which is reading/writing
|
|
|
|
* from user space. Such code must not hold kernel locks (since it
|
|
|
|
* can equally take a page fault), therefore it is safe to call
|
|
|
|
* force_sig_info even though that claims and releases locks.
|
2008-02-26 18:15:50 +08:00
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* Code in ./signal.c ensures that the debug control register
|
|
|
|
* is restored before we deliver any signal, and therefore that
|
|
|
|
* user code runs with the correct debug control register even though
|
|
|
|
* we clear it here.
|
|
|
|
*
|
|
|
|
* Being careful here means that we don't have to be as careful in a
|
|
|
|
* lot of more complicated places (task switching can be a bit lazy
|
|
|
|
* about restoring all the debug state, and ptrace doesn't have to
|
|
|
|
* find every occurrence of the TF bit that could be saved away even
|
|
|
|
* by user code)
|
2008-10-04 05:17:11 +08:00
|
|
|
*
|
|
|
|
* May run on IST stack.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2014-04-17 16:18:14 +08:00
|
|
|
dotraplinkage void do_debug(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct task_struct *tsk = current;
|
2010-06-30 21:09:06 +08:00
|
|
|
int user_icebp = 0;
|
2009-06-02 02:14:08 +08:00
|
|
|
unsigned long dr6;
|
2008-09-23 17:53:52 +08:00
|
|
|
int si_code;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-07-04 03:44:32 +08:00
|
|
|
ist_enter(regs);
|
2014-06-14 14:47:12 +08:00
|
|
|
|
2009-06-02 02:14:08 +08:00
|
|
|
get_debugreg(dr6, 6);
|
2016-03-10 11:00:29 +08:00
|
|
|
/*
|
|
|
|
* The Intel SDM says:
|
|
|
|
*
|
|
|
|
* Certain debug exceptions may clear bits 0-3. The remaining
|
|
|
|
* contents of the DR6 register are never cleared by the
|
|
|
|
* processor. To avoid confusion in identifying debug
|
|
|
|
* exceptions, debug handlers should clear the register before
|
|
|
|
* returning to the interrupted task.
|
|
|
|
*
|
|
|
|
* Keep it simple: clear DR6 immediately.
|
|
|
|
*/
|
|
|
|
set_debugreg(0, 6);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-01-28 19:14:01 +08:00
|
|
|
/* Filter out all the reserved bits which are preset to 1 */
|
|
|
|
dr6 &= ~DR6_RESERVED;
|
|
|
|
|
2016-03-10 11:00:28 +08:00
|
|
|
/*
|
|
|
|
* The SDM says "The processor clears the BTF flag when it
|
|
|
|
* generates a debug exception." Clear TIF_BLOCKSTEP to keep
|
|
|
|
* TIF_BLOCKSTEP in sync with the hardware BTF flag.
|
|
|
|
*/
|
|
|
|
clear_tsk_thread_flag(tsk, TIF_BLOCKSTEP);
|
|
|
|
|
2016-03-10 11:00:30 +08:00
|
|
|
if (unlikely(!user_mode(regs) && (dr6 & DR_STEP) &&
|
|
|
|
is_sysenter_singlestep(regs))) {
|
|
|
|
dr6 &= ~DR_STEP;
|
|
|
|
if (!dr6)
|
|
|
|
goto exit;
|
|
|
|
/*
|
|
|
|
* else we might have gotten a single-step trap and hit a
|
|
|
|
* watchpoint at the same time, in which case we should fall
|
|
|
|
* through and handle the watchpoint.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
2010-06-30 21:09:06 +08:00
|
|
|
/*
|
|
|
|
* If dr6 has no reason to give us about the origin of this trap,
|
|
|
|
* then it's very likely the result of an icebp/int01 trap.
|
|
|
|
* User wants a sigtrap for that.
|
|
|
|
*/
|
2015-03-19 09:33:33 +08:00
|
|
|
if (!dr6 && user_mode(regs))
|
2010-06-30 21:09:06 +08:00
|
|
|
user_icebp = 1;
|
|
|
|
|
2009-06-02 02:14:08 +08:00
|
|
|
/* Store the virtualized DR6 value */
|
|
|
|
tsk->thread.debugreg6 = dr6;
|
|
|
|
|
kprobes/x86: Call exception handlers directly from do_int3/do_debug
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler() and kprobe_debug_handler()(which was
formerly called post_kprobe_handler()) directly from
do_int3 and do_debug.
Currently kprobes uses notify_die() to hook the int3/debug
exceptoins. Since there is a locking code in notify_die,
the lockdep code can be invoked. And because the lockdep
involves printk() related things, theoretically, we need to
prohibit probing on such code, which means much longer blacklist
we'll have. Instead, hooking the int3/debug for kprobes before
notify_die() can avoid this problem.
Anyway, most of the int3 handlers in the kernel are already
called from do_int3 directly, e.g. ftrace_int3_handler,
poke_int3_handler, kgdb_ll_trap. Actually only
kprobe_exceptions_notify is on the notifier_call_chain.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Lebon <jlebon@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/20140417081733.26341.24423.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-04-17 16:17:33 +08:00
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_debug_handler(regs))
|
|
|
|
goto exit;
|
|
|
|
#endif
|
|
|
|
|
2013-06-16 12:42:47 +08:00
|
|
|
if (notify_die(DIE_DEBUG, "debug", regs, (long)&dr6, error_code,
|
2009-06-02 02:17:06 +08:00
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2008-10-01 00:41:37 +08:00
|
|
|
|
2011-12-17 00:43:02 +08:00
|
|
|
/*
|
|
|
|
* Let others (NMI) know that the debug stack is in use
|
|
|
|
* as we may switch to the interrupt stack.
|
|
|
|
*/
|
|
|
|
debug_stack_usage_inc();
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* It's safe to allow irq's after DR6 has been saved */
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-03-19 09:33:35 +08:00
|
|
|
if (v8086_mode(regs)) {
|
2012-03-10 08:07:10 +08:00
|
|
|
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
|
|
|
|
X86_TRAP_DB);
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2011-12-17 00:43:02 +08:00
|
|
|
debug_stack_usage_dec();
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-03-10 11:00:30 +08:00
|
|
|
if (WARN_ON_ONCE((dr6 & DR_STEP) && !user_mode(regs))) {
|
|
|
|
/*
|
|
|
|
* Historical junk that used to handle SYSENTER single-stepping.
|
|
|
|
* This should be unreachable now. If we survive for a while
|
|
|
|
* without anyone hitting this warning, we'll turn this into
|
|
|
|
* an oops.
|
|
|
|
*/
|
2009-06-02 02:14:08 +08:00
|
|
|
tsk->thread.debugreg6 &= ~DR_STEP;
|
|
|
|
set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
|
|
|
|
regs->flags &= ~X86_EFLAGS_TF;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2009-06-02 02:14:08 +08:00
|
|
|
si_code = get_si_code(tsk->thread.debugreg6);
|
2010-06-30 21:09:06 +08:00
|
|
|
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
|
2009-06-02 02:14:08 +08:00
|
|
|
send_sigtrap(tsk, regs, error_code, si_code);
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2011-12-17 00:43:02 +08:00
|
|
|
debug_stack_usage_dec();
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-07-12 02:26:35 +08:00
|
|
|
exit:
|
2015-07-04 03:44:32 +08:00
|
|
|
ist_exit(regs);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_debug);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that we play around with the 'TS' bit in an attempt to get
|
|
|
|
* the correct behaviour even in the presence of the asynchronous
|
|
|
|
* IRQ13 behaviour
|
|
|
|
*/
|
2014-05-09 02:34:00 +08:00
|
|
|
static void math_error(struct pt_regs *regs, int error_code, int trapnr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-03-21 21:00:45 +08:00
|
|
|
struct task_struct *task = current;
|
2015-04-30 15:29:38 +08:00
|
|
|
struct fpu *fpu = &task->thread.fpu;
|
2018-09-18 07:16:39 +08:00
|
|
|
int si_code;
|
2012-03-10 08:07:10 +08:00
|
|
|
char *str = (trapnr == X86_TRAP_MF) ? "fpu exception" :
|
|
|
|
"simd exception";
|
2010-03-21 21:00:45 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2010-03-21 21:00:45 +08:00
|
|
|
|
2015-04-30 15:29:38 +08:00
|
|
|
if (!user_mode(regs)) {
|
2018-08-29 04:14:19 +08:00
|
|
|
if (fixup_exception(regs, trapnr, error_code, 0))
|
2018-06-15 03:36:07 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
task->thread.error_code = error_code;
|
|
|
|
task->thread.trap_nr = trapnr;
|
|
|
|
|
|
|
|
if (notify_die(DIE_TRAP, str, regs, error_code,
|
|
|
|
trapnr, SIGFPE) != NOTIFY_STOP)
|
2010-03-21 21:00:45 +08:00
|
|
|
die(str, regs, error_code);
|
|
|
|
return;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Save the info for the exception handler and clear the error.
|
|
|
|
*/
|
2015-04-30 15:29:38 +08:00
|
|
|
fpu__save(fpu);
|
|
|
|
|
|
|
|
task->thread.trap_nr = trapnr;
|
2010-03-21 21:00:44 +08:00
|
|
|
task->thread.error_code = error_code;
|
2008-12-23 09:56:05 +08:00
|
|
|
|
2018-09-18 07:16:39 +08:00
|
|
|
si_code = fpu__exception_code(fpu, trapnr);
|
2015-04-30 15:29:38 +08:00
|
|
|
/* Retry when we get spurious exceptions: */
|
2018-09-18 07:16:39 +08:00
|
|
|
if (!si_code)
|
2012-03-10 08:07:10 +08:00
|
|
|
return;
|
2015-04-30 15:29:38 +08:00
|
|
|
|
2018-09-18 07:16:39 +08:00
|
|
|
force_sig_fault(SIGFPE, si_code,
|
|
|
|
(void __user *)uprobe_get_trap_addr(regs), task);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2008-10-01 00:41:36 +08:00
|
|
|
dotraplinkage void do_coprocessor_error(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2012-03-10 08:07:10 +08:00
|
|
|
math_error(regs, error_code, X86_TRAP_MF);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2008-10-01 00:41:36 +08:00
|
|
|
dotraplinkage void
|
|
|
|
do_simd_coprocessor_error(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2012-03-10 08:07:10 +08:00
|
|
|
math_error(regs, error_code, X86_TRAP_XF);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2008-10-01 00:41:36 +08:00
|
|
|
dotraplinkage void
|
|
|
|
do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2008-10-04 04:00:39 +08:00
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
dotraplinkage void
|
2009-02-10 22:51:45 +08:00
|
|
|
do_device_not_available(struct pt_regs *regs, long error_code)
|
2008-09-10 03:56:02 +08:00
|
|
|
{
|
2019-01-17 20:02:05 +08:00
|
|
|
unsigned long cr0 = read_cr0();
|
2016-11-01 06:18:47 +08:00
|
|
|
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2012-08-25 05:13:02 +08:00
|
|
|
|
2010-09-04 09:17:15 +08:00
|
|
|
#ifdef CONFIG_MATH_EMULATION
|
2019-01-17 20:02:05 +08:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_FPU) && (cr0 & X86_CR0_EM)) {
|
2009-02-09 21:17:39 +08:00
|
|
|
struct math_emu_info info = { };
|
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2009-02-09 21:17:39 +08:00
|
|
|
|
2009-02-10 22:51:45 +08:00
|
|
|
info.regs = regs;
|
2009-02-09 21:17:39 +08:00
|
|
|
math_emulate(&info);
|
2010-09-04 09:17:15 +08:00
|
|
|
return;
|
2008-09-10 03:56:02 +08:00
|
|
|
}
|
2010-09-04 09:17:15 +08:00
|
|
|
#endif
|
2016-11-01 06:18:47 +08:00
|
|
|
|
|
|
|
/* This should not happen. */
|
|
|
|
if (WARN(cr0 & X86_CR0_TS, "CR0.TS was set")) {
|
|
|
|
/* Try to fix it up and carry on. */
|
|
|
|
write_cr0(cr0 & ~X86_CR0_TS);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Something terrible happened, and we're better off trying
|
|
|
|
* to kill the task than getting stuck in a never-ending
|
|
|
|
* loop of #NM faults.
|
|
|
|
*/
|
|
|
|
die("unexpected #NM exception", regs, error_code);
|
|
|
|
}
|
2008-09-10 03:56:02 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_device_not_available);
|
2008-09-10 03:56:02 +08:00
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_32
|
2008-10-01 00:41:36 +08:00
|
|
|
dotraplinkage void do_iret_error(struct pt_regs *regs, long error_code)
|
2008-09-10 03:56:13 +08:00
|
|
|
{
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2008-09-10 03:56:13 +08:00
|
|
|
local_irq_enable();
|
|
|
|
|
2012-03-10 08:07:10 +08:00
|
|
|
if (notify_die(DIE_TRAP, "iret exception", regs, error_code,
|
2012-07-12 02:26:35 +08:00
|
|
|
X86_TRAP_IRET, SIGILL) != NOTIFY_STOP) {
|
|
|
|
do_trap(X86_TRAP_IRET, SIGILL, "iret exception", regs, error_code,
|
2018-04-17 03:29:39 +08:00
|
|
|
ILL_BADSTK, (void __user *)NULL);
|
2012-07-12 02:26:35 +08:00
|
|
|
}
|
2008-09-10 03:56:13 +08:00
|
|
|
}
|
2008-10-04 04:00:39 +08:00
|
|
|
#endif
|
2008-09-10 03:56:13 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
void __init trap_init(void)
|
|
|
|
{
|
2017-12-04 22:07:26 +08:00
|
|
|
/* Init cpu_entry_area before IST entries are set up */
|
|
|
|
setup_cpu_entry_areas();
|
|
|
|
|
2017-08-28 14:47:53 +08:00
|
|
|
idt_setup_traps();
|
2009-01-25 18:38:09 +08:00
|
|
|
|
2013-04-11 03:24:22 +08:00
|
|
|
/*
|
|
|
|
* Set the IDT descriptor to a fixed read-only location, so that the
|
|
|
|
* "sidt" instruction will not leak the location of the kernel, and
|
|
|
|
* to defend the IDT against arbitrary memory write vulnerabilities.
|
|
|
|
* It will be reloaded in cpu_init() */
|
2017-12-21 01:51:31 +08:00
|
|
|
cea_set_pte(CPU_ENTRY_AREA_RO_IDT_VADDR, __pa_symbol(idt_table),
|
|
|
|
PAGE_KERNEL_RO);
|
|
|
|
idt_descr.address = CPU_ENTRY_AREA_RO_IDT;
|
2013-04-11 03:24:22 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2008-02-26 18:15:50 +08:00
|
|
|
* Should be a barrier for any external CPU state:
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
cpu_init();
|
|
|
|
|
2017-08-28 14:47:52 +08:00
|
|
|
idt_setup_ist_traps();
|
2015-02-26 13:49:39 +08:00
|
|
|
|
2009-08-20 16:35:46 +08:00
|
|
|
x86_init.irqs.trap_init();
|
2011-12-09 16:02:19 +08:00
|
|
|
|
2017-08-28 14:47:51 +08:00
|
|
|
idt_setup_debugidt_traps();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|