2005-04-17 05:20:36 +07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
2008-07-02 06:29:44 +07:00
|
|
|
* Copyright (C) 2000, 2001, 2002 Andi Kleen, SuSE Labs
|
2005-04-17 05:20:36 +07:00
|
|
|
*
|
|
|
|
* Pentium III FXSR, SSE support
|
|
|
|
* Gareth Hughes <gareth@valinux.com>, May 2000
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2008-10-04 04:17:11 +07:00
|
|
|
* Handle hardware traps and faults.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2012-05-22 09:50:07 +07:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2013-02-24 06:23:25 +07:00
|
|
|
#include <linux/context_tracking.h>
|
2008-02-26 17:15:50 +07: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 09:04:25 +07:00
|
|
|
#include <linux/kgdb.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/kernel.h>
|
2016-07-14 07:18:56 +07:00
|
|
|
#include <linux/export.h>
|
2008-02-26 17:15:50 +07: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-12 23:24:45 +07:00
|
|
|
#include <linux/uprobes.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/string.h>
|
2008-02-26 17:15:50 +07:00
|
|
|
#include <linux/delay.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/errno.h>
|
2008-02-26 17:15:50 +07:00
|
|
|
#include <linux/kexec.h>
|
|
|
|
#include <linux/sched.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <linux/timer.h>
|
|
|
|
#include <linux/init.h>
|
2006-12-08 17:36:21 +07:00
|
|
|
#include <linux/bug.h>
|
2008-02-26 17:15:50 +07:00
|
|
|
#include <linux/nmi.h>
|
|
|
|
#include <linux/mm.h>
|
2008-10-04 04:17:11 +07:00
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/io.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_EISA
|
|
|
|
#include <linux/ioport.h>
|
|
|
|
#include <linux/eisa.h>
|
|
|
|
#endif
|
|
|
|
|
2007-07-19 15:49:46 +07:00
|
|
|
#if defined(CONFIG_EDAC)
|
|
|
|
#include <linux/edac.h>
|
|
|
|
#endif
|
|
|
|
|
2008-04-04 05:53:23 +07:00
|
|
|
#include <asm/kmemcheck.h>
|
2008-02-26 17:15:50 +07:00
|
|
|
#include <asm/stacktrace.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/debugreg.h>
|
2011-07-27 06:09:06 +07:00
|
|
|
#include <linux/atomic.h>
|
2016-04-27 02:23:24 +07:00
|
|
|
#include <asm/text-patching.h>
|
2011-08-16 20:57:10 +07:00
|
|
|
#include <asm/ftrace.h>
|
2008-10-04 04:17:11 +07:00
|
|
|
#include <asm/traps.h>
|
2005-04-17 05:20:36 +07:00
|
|
|
#include <asm/desc.h>
|
2015-04-24 07:54:44 +07:00
|
|
|
#include <asm/fpu/internal.h>
|
2009-06-15 15:22:15 +07:00
|
|
|
#include <asm/mce.h>
|
2013-04-11 02:24:22 +07:00
|
|
|
#include <asm/fixmap.h>
|
2009-01-29 01:34:09 +07:00
|
|
|
#include <asm/mach_traps.h>
|
2013-07-23 15:09:28 +07:00
|
|
|
#include <asm/alternative.h>
|
2015-06-08 01:37:01 +07:00
|
|
|
#include <asm/fpu/xstate.h>
|
2015-06-08 01:37:03 +07: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 22:18:29 +07:00
|
|
|
#include <asm/mpx.h>
|
2015-07-29 12:41:21 +07:00
|
|
|
#include <asm/vm86.h>
|
2008-10-04 04:17:11 +07:00
|
|
|
|
2008-10-04 03:00:39 +07:00
|
|
|
#ifdef CONFIG_X86_64
|
2009-08-20 15:35:46 +07:00
|
|
|
#include <asm/x86_init.h>
|
2008-10-04 03:00:39 +07:00
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/proto.h>
|
2013-07-17 01:34:41 +07:00
|
|
|
|
|
|
|
/* No need to be aligned, but done to keep all IDTs defined the same way. */
|
|
|
|
gate_desc debug_idt_table[NR_VECTORS] __page_aligned_bss;
|
2008-10-04 03:00:39 +07:00
|
|
|
#else
|
2008-10-04 04:17:11 +07:00
|
|
|
#include <asm/processor-flags.h>
|
2009-02-23 06:34:39 +07:00
|
|
|
#include <asm/setup.h>
|
2015-06-08 13:42:03 +07:00
|
|
|
#include <asm/proto.h>
|
2008-10-04 03:00:39 +07:00
|
|
|
#endif
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2013-07-17 01:34:41 +07:00
|
|
|
/* Must be page-aligned because the real IDT is used in a fixmap. */
|
|
|
|
gate_desc idt_table[NR_VECTORS] __page_aligned_bss;
|
|
|
|
|
2008-12-20 06:23:44 +07:00
|
|
|
DECLARE_BITMAP(used_vectors, NR_VECTORS);
|
|
|
|
EXPORT_SYMBOL_GPL(used_vectors);
|
|
|
|
|
2016-01-26 02:41:46 +07:00
|
|
|
static inline void cond_local_irq_enable(struct pt_regs *regs)
|
2008-09-10 02:55:55 +07:00
|
|
|
{
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
local_irq_enable();
|
|
|
|
}
|
|
|
|
|
2016-01-26 02:41:46 +07:00
|
|
|
static inline void cond_local_irq_disable(struct pt_regs *regs)
|
2008-09-30 23:41:37 +07:00
|
|
|
{
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
local_irq_disable();
|
|
|
|
}
|
|
|
|
|
2016-05-25 05:54:04 +07: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 02:44:32 +07:00
|
|
|
void ist_enter(struct pt_regs *regs)
|
2014-11-20 08:41:09 +07:00
|
|
|
{
|
2015-03-19 08:33:33 +07:00
|
|
|
if (user_mode(regs)) {
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2014-11-20 08:41:09 +07: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 19:53:53 +07:00
|
|
|
|
2016-05-25 05:54:04 +07:00
|
|
|
preempt_disable();
|
2015-01-31 19:53:53 +07:00
|
|
|
|
|
|
|
/* This code is a bit fragile. Test it. */
|
2015-06-19 05:50:02 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "ist_enter didn't work");
|
2014-11-20 08:41:09 +07:00
|
|
|
}
|
|
|
|
|
2015-07-04 02:44:32 +07:00
|
|
|
void ist_exit(struct pt_regs *regs)
|
2014-11-20 08:41:09 +07:00
|
|
|
{
|
2016-05-25 05:54:04 +07:00
|
|
|
preempt_enable_no_resched();
|
2014-11-20 08:41:09 +07:00
|
|
|
|
2015-07-04 02:44:32 +07:00
|
|
|
if (!user_mode(regs))
|
2014-11-20 08:41:09 +07:00
|
|
|
rcu_nmi_exit();
|
|
|
|
}
|
|
|
|
|
2014-11-20 08:59:41 +07: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 08:33:33 +07:00
|
|
|
* user_mode(regs) would return true) and the exception was not
|
2014-11-20 08:59:41 +07: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 02:44:32 +07:00
|
|
|
* the non-atomic section, and callers must call ist_end_non_atomic()
|
2014-11-20 08:59:41 +07:00
|
|
|
* before ist_exit().
|
|
|
|
*/
|
|
|
|
void ist_begin_non_atomic(struct pt_regs *regs)
|
|
|
|
{
|
2015-03-19 08:33:33 +07:00
|
|
|
BUG_ON(!user_mode(regs));
|
2014-11-20 08:59:41 +07: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.
|
|
|
|
*/
|
2015-03-07 08:50:19 +07:00
|
|
|
BUG_ON((unsigned long)(current_top_of_stack() -
|
|
|
|
current_stack_pointer()) >= THREAD_SIZE);
|
2014-11-20 08:59:41 +07:00
|
|
|
|
2016-05-25 05:54:04 +07:00
|
|
|
preempt_enable_no_resched();
|
2014-11-20 08:59:41 +07: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 05:54:04 +07:00
|
|
|
preempt_disable();
|
2014-11-20 08:59:41 +07:00
|
|
|
}
|
|
|
|
|
2014-04-17 15:18:14 +07:00
|
|
|
static nokprobe_inline int
|
2012-09-25 19:51:19 +07:00
|
|
|
do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str,
|
|
|
|
struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2015-03-19 08:33:35 +07:00
|
|
|
if (v8086_mode(regs)) {
|
2008-09-26 19:03:08 +07:00
|
|
|
/*
|
2012-09-25 19:51:19 +07:00
|
|
|
* Traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
|
2008-09-26 19:03:08 +07:00
|
|
|
* On nmi (interrupt 2), do_trap should not be called.
|
|
|
|
*/
|
2012-09-25 19:51:19 +07:00
|
|
|
if (trapnr < X86_TRAP_UD) {
|
|
|
|
if (!handle_vm86_trap((struct kernel_vm86_regs *) regs,
|
|
|
|
error_code, trapnr))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return -1;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2015-03-19 08:33:35 +07:00
|
|
|
|
2015-03-29 16:02:34 +07:00
|
|
|
if (!user_mode(regs)) {
|
2016-02-18 01:20:12 +07:00
|
|
|
if (!fixup_exception(regs, trapnr)) {
|
2012-09-25 19:51:19 +07:00
|
|
|
tsk->thread.error_code = error_code;
|
|
|
|
tsk->thread.trap_nr = trapnr;
|
|
|
|
die(str, regs, error_code);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2012-09-25 19:51:19 +07:00
|
|
|
return -1;
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2014-05-09 01:04:11 +07:00
|
|
|
static siginfo_t *fill_trap_info(struct pt_regs *regs, int signr, int trapnr,
|
|
|
|
siginfo_t *info)
|
2014-05-07 22:59:39 +07:00
|
|
|
{
|
|
|
|
unsigned long siaddr;
|
|
|
|
int sicode;
|
|
|
|
|
|
|
|
switch (trapnr) {
|
2014-05-09 01:04:11 +07:00
|
|
|
default:
|
|
|
|
return SEND_SIG_PRIV;
|
|
|
|
|
2014-05-07 22:59:39 +07:00
|
|
|
case X86_TRAP_DE:
|
|
|
|
sicode = FPE_INTDIV;
|
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-12 23:24:45 +07:00
|
|
|
siaddr = uprobe_get_trap_addr(regs);
|
2014-05-07 22:59:39 +07:00
|
|
|
break;
|
|
|
|
case X86_TRAP_UD:
|
|
|
|
sicode = ILL_ILLOPN;
|
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-12 23:24:45 +07:00
|
|
|
siaddr = uprobe_get_trap_addr(regs);
|
2014-05-07 22:59:39 +07:00
|
|
|
break;
|
|
|
|
case X86_TRAP_AC:
|
|
|
|
sicode = BUS_ADRALN;
|
|
|
|
siaddr = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
info->si_signo = signr;
|
|
|
|
info->si_errno = 0;
|
|
|
|
info->si_code = sicode;
|
|
|
|
info->si_addr = (void __user *)siaddr;
|
2014-05-09 01:04:11 +07:00
|
|
|
return info;
|
2014-05-07 22:59:39 +07:00
|
|
|
}
|
|
|
|
|
2014-04-17 15:18:14 +07:00
|
|
|
static void
|
2012-09-25 19:51:19 +07:00
|
|
|
do_trap(int trapnr, int signr, char *str, struct pt_regs *regs,
|
|
|
|
long error_code, siginfo_t *info)
|
|
|
|
{
|
|
|
|
struct task_struct *tsk = current;
|
|
|
|
|
|
|
|
|
|
|
|
if (!do_trap_no_signal(tsk, trapnr, str, regs, error_code))
|
|
|
|
return;
|
2008-02-26 17:15:50 +07:00
|
|
|
/*
|
2012-03-12 16:25:55 +07:00
|
|
|
* We want error_code and trap_nr set for userspace faults and
|
2008-02-26 17:15:50 +07: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 16:25:55 +07:00
|
|
|
tsk->thread.trap_nr = trapnr;
|
2007-05-03 00:27:05 +07:00
|
|
|
|
2008-10-04 03:00:39 +07:00
|
|
|
if (show_unhandled_signals && unhandled_signal(tsk, signr) &&
|
|
|
|
printk_ratelimit()) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("%s[%d] trap %s ip:%lx sp:%lx error:%lx",
|
|
|
|
tsk->comm, tsk->pid, str,
|
|
|
|
regs->ip, regs->sp, error_code);
|
2008-10-04 03:00:39 +07:00
|
|
|
print_vma_addr(" in ", regs->ip);
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_cont("\n");
|
2008-10-04 03:00:39 +07:00
|
|
|
}
|
|
|
|
|
2014-05-07 21:47:09 +07:00
|
|
|
force_sig_info(signr, info ?: SEND_SIG_PRIV, tsk);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2014-04-17 15:18:14 +07:00
|
|
|
NOKPROBE_SYMBOL(do_trap);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2014-05-07 22:21:34 +07:00
|
|
|
static void do_error_trap(struct pt_regs *regs, long error_code, char *str,
|
2014-05-09 01:04:11 +07:00
|
|
|
unsigned long trapnr, int signr)
|
2014-05-07 22:21:34 +07:00
|
|
|
{
|
2014-05-09 01:04:11 +07:00
|
|
|
siginfo_t info;
|
2014-05-07 22:21:34 +07:00
|
|
|
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2015-07-04 02:44:24 +07:00
|
|
|
|
2014-05-07 22:21:34 +07:00
|
|
|
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
|
|
|
|
NOTIFY_STOP) {
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_enable(regs);
|
2014-05-09 01:04:11 +07:00
|
|
|
do_trap(trapnr, signr, str, regs, error_code,
|
|
|
|
fill_trap_info(regs, signr, trapnr, &info));
|
2014-05-07 22:21:34 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-02-26 17:15:50 +07:00
|
|
|
#define DO_ERROR(trapnr, signr, str, name) \
|
2008-09-30 23:41:36 +07:00
|
|
|
dotraplinkage void do_##name(struct pt_regs *regs, long error_code) \
|
2008-02-26 17:15:50 +07:00
|
|
|
{ \
|
2014-05-09 01:04:11 +07:00
|
|
|
do_error_trap(regs, error_code, str, trapnr, signr); \
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2014-05-09 01:12:24 +07:00
|
|
|
DO_ERROR(X86_TRAP_DE, SIGFPE, "divide error", divide_error)
|
|
|
|
DO_ERROR(X86_TRAP_OF, SIGSEGV, "overflow", overflow)
|
|
|
|
DO_ERROR(X86_TRAP_UD, SIGILL, "invalid opcode", invalid_op)
|
|
|
|
DO_ERROR(X86_TRAP_OLD_MF, SIGFPE, "coprocessor segment overrun",coprocessor_segment_overrun)
|
|
|
|
DO_ERROR(X86_TRAP_TS, SIGSEGV, "invalid TSS", invalid_TSS)
|
|
|
|
DO_ERROR(X86_TRAP_NP, SIGBUS, "segment not present", segment_not_present)
|
|
|
|
DO_ERROR(X86_TRAP_SS, SIGBUS, "stack segment", stack_segment)
|
|
|
|
DO_ERROR(X86_TRAP_AC, SIGBUS, "alignment check", alignment_check)
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2016-08-11 16:35:23 +07:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
2016-08-31 07:27:57 +07:00
|
|
|
__visible void __noreturn handle_stack_overflow(const char *message,
|
|
|
|
struct pt_regs *regs,
|
|
|
|
unsigned long fault_address)
|
2016-08-11 16:35:23 +07: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. */
|
|
|
|
panic(message);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-10-04 03:00:39 +07: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 16:35:23 +07:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
|
|
|
unsigned long cr2;
|
|
|
|
#endif
|
2008-10-04 03:00:39 +07:00
|
|
|
|
2014-11-23 09:00:31 +07: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
|
|
|
|
* end up promoting it to a doublefault. In that case, modify
|
|
|
|
* the stack to make it look like we just entered the #GP
|
|
|
|
* handler from user space, similar to bad_iret.
|
2014-11-20 08:41:09 +07:00
|
|
|
*
|
|
|
|
* No need for ist_enter here because we don't use RCU.
|
2014-11-23 09:00:31 +07:00
|
|
|
*/
|
|
|
|
if (((long)regs->sp >> PGDIR_SHIFT) == ESPFIX_PGD_ENTRY &&
|
|
|
|
regs->cs == __KERNEL_CS &&
|
|
|
|
regs->ip == (unsigned long)native_irq_return_iret)
|
|
|
|
{
|
|
|
|
struct pt_regs *normal_regs = task_pt_regs(current);
|
|
|
|
|
|
|
|
/* Fake a #GP(0) from userspace. */
|
|
|
|
memmove(&normal_regs->ip, (void *)regs->sp, 5*8);
|
|
|
|
normal_regs->orig_ax = 0; /* Missing (lost) #GP error code */
|
|
|
|
regs->ip = (unsigned long)general_protection;
|
|
|
|
regs->sp = (unsigned long)&normal_regs->orig_ax;
|
2014-11-20 08:41:09 +07:00
|
|
|
|
2014-11-23 09:00:31 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2015-07-04 02:44:32 +07:00
|
|
|
ist_enter(regs);
|
2012-03-10 07:07:10 +07:00
|
|
|
notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_DF, SIGSEGV);
|
2008-10-04 03:00:39 +07:00
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 16:25:55 +07:00
|
|
|
tsk->thread.trap_nr = X86_TRAP_DF;
|
2008-10-04 03:00:39 +07:00
|
|
|
|
2016-08-11 16:35:23 +07: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
|
|
|
|
* deliv- ered, the faulting linear address of the second fault will
|
|
|
|
* 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 17:02:29 +07:00
|
|
|
#ifdef CONFIG_DOUBLEFAULT
|
|
|
|
df_debug(regs, error_code);
|
|
|
|
#endif
|
2008-12-26 15:20:22 +07:00
|
|
|
/*
|
|
|
|
* This is always a kernel trap and never fixable (and thus must
|
|
|
|
* never return).
|
|
|
|
*/
|
2008-10-04 03:00:39 +07: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 22:18:29 +07:00
|
|
|
dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
|
|
|
|
{
|
2015-09-03 06:31:29 +07: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 22:18:29 +07:00
|
|
|
siginfo_t *info;
|
|
|
|
|
2015-09-01 22:40:25 +07: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 22:18:29 +07:00
|
|
|
if (notify_die(DIE_TRAP, "bounds", regs, error_code,
|
|
|
|
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
|
2015-07-04 02:44:32 +07:00
|
|
|
return;
|
2016-01-26 02:41:46 +07: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 22:18:29 +07:00
|
|
|
|
2015-03-19 08:33:33 +07: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 22:18:29 +07: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 01:37:01 +07: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 22:18:29 +07:00
|
|
|
*/
|
2015-09-03 06:31:26 +07:00
|
|
|
bndcsr = get_xsave_field_ptr(XFEATURE_MASK_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 22:18:29 +07:00
|
|
|
if (!bndcsr)
|
|
|
|
goto exit_trap;
|
|
|
|
|
2015-06-08 01:37:03 +07: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 22:18:29 +07: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 01:37:02 +07: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 22:18:29 +07:00
|
|
|
goto exit_trap;
|
|
|
|
break; /* Success, it was handled */
|
|
|
|
case 1: /* Bound violation. */
|
2015-06-08 01:37:02 +07:00
|
|
|
info = mpx_generate_siginfo(regs);
|
2014-11-26 00:21:14 +07:00
|
|
|
if (IS_ERR(info)) {
|
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 22:18:29 +07: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
|
|
|
|
* an 'info' containing the address being accessed
|
|
|
|
* which caused the exception. This information
|
|
|
|
* allows and application to possibly handle the
|
|
|
|
* #BR exception itself.
|
|
|
|
*/
|
|
|
|
do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, info);
|
|
|
|
kfree(info);
|
|
|
|
break;
|
|
|
|
case 0: /* No exception caused by Intel MPX operations. */
|
|
|
|
goto exit_trap;
|
|
|
|
default:
|
|
|
|
die("bounds", regs, error_code);
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
2015-07-04 02:44:32 +07: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 22:18:29 +07: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..
|
|
|
|
*/
|
|
|
|
do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, error_code, NULL);
|
|
|
|
}
|
|
|
|
|
2014-04-17 15:18:14 +07:00
|
|
|
dotraplinkage void
|
2008-07-02 06:32:04 +07:00
|
|
|
do_general_protection(struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2008-07-02 06:32:04 +07:00
|
|
|
struct task_struct *tsk;
|
2008-02-26 17:15:50 +07:00
|
|
|
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_enable(regs);
|
2008-09-10 02:56:07 +07:00
|
|
|
|
2015-03-19 08:33:35 +07:00
|
|
|
if (v8086_mode(regs)) {
|
2012-09-25 02:05:52 +07:00
|
|
|
local_irq_enable();
|
|
|
|
handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
|
2015-07-04 02:44:32 +07:00
|
|
|
return;
|
2012-09-25 02:05:52 +07:00
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-07-02 06:32:04 +07:00
|
|
|
tsk = current;
|
2015-03-29 16:02:34 +07:00
|
|
|
if (!user_mode(regs)) {
|
2016-02-18 01:20:12 +07:00
|
|
|
if (fixup_exception(regs, X86_TRAP_GP))
|
2015-07-04 02:44:32 +07:00
|
|
|
return;
|
2012-09-25 02:05:52 +07:00
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
|
|
|
tsk->thread.trap_nr = X86_TRAP_GP;
|
2012-07-12 01:26:35 +07:00
|
|
|
if (notify_die(DIE_GPF, "general protection fault", regs, error_code,
|
|
|
|
X86_TRAP_GP, SIGSEGV) != NOTIFY_STOP)
|
2012-09-25 02:05:52 +07:00
|
|
|
die("general protection fault", regs, error_code);
|
2015-07-04 02:44:32 +07:00
|
|
|
return;
|
2012-09-25 02:05:52 +07:00
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-07-02 06:32:04 +07:00
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 16:25:55 +07:00
|
|
|
tsk->thread.trap_nr = X86_TRAP_GP;
|
2008-02-26 17:15:50 +07:00
|
|
|
|
2008-07-02 06:32:04 +07:00
|
|
|
if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&
|
|
|
|
printk_ratelimit()) {
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_info("%s[%d] general protection ip:%lx sp:%lx error:%lx",
|
2008-07-02 06:32:04 +07:00
|
|
|
tsk->comm, task_pid_nr(tsk),
|
|
|
|
regs->ip, regs->sp, error_code);
|
2008-01-30 19:33:18 +07:00
|
|
|
print_vma_addr(" in ", regs->ip);
|
2012-05-22 09:50:07 +07:00
|
|
|
pr_cont("\n");
|
2008-01-30 19:33:18 +07:00
|
|
|
}
|
2007-07-22 16:12:28 +07:00
|
|
|
|
2014-05-07 21:47:09 +07:00
|
|
|
force_sig_info(SIGSEGV, SEND_SIG_PRIV, tsk);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2014-04-17 15:18:14 +07:00
|
|
|
NOKPROBE_SYMBOL(do_general_protection);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-10-04 04:17:11 +07:00
|
|
|
/* May run on IST stack. */
|
2014-04-17 15:18:14 +07:00
|
|
|
dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2011-08-16 20:57:10 +07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
2012-05-31 00:26:37 +07: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 20:57:10 +07:00
|
|
|
return;
|
|
|
|
#endif
|
2013-07-23 15:09:28 +07:00
|
|
|
if (poke_int3_handler(regs))
|
|
|
|
return;
|
|
|
|
|
2015-07-04 02:44:32 +07:00
|
|
|
ist_enter(regs);
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2010-05-21 09:04:25 +07:00
|
|
|
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
|
2012-03-10 07:07:10 +07:00
|
|
|
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 01:26:35 +07:00
|
|
|
goto exit;
|
2010-05-21 09:04:25 +07:00
|
|
|
#endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
|
2011-10-25 21:21:59 +07: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 15:17:33 +07:00
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_int3_handler(regs))
|
2014-06-14 13:47:12 +07: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 15:17:33 +07:00
|
|
|
#endif
|
|
|
|
|
2012-03-10 07:07:10 +07:00
|
|
|
if (notify_die(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 01:26:35 +07:00
|
|
|
goto exit;
|
2008-02-26 17:15:50 +07:00
|
|
|
|
2011-12-16 23:43:02 +07:00
|
|
|
/*
|
|
|
|
* Let others (NMI) know that the debug stack is in use
|
|
|
|
* as we may switch to the interrupt stack.
|
|
|
|
*/
|
|
|
|
debug_stack_usage_inc();
|
2016-01-26 02:41:46 +07:00
|
|
|
preempt_disable();
|
|
|
|
cond_local_irq_enable(regs);
|
2012-03-10 07:07:10 +07:00
|
|
|
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_disable(regs);
|
|
|
|
preempt_enable_no_resched();
|
2011-12-16 23:43:02 +07:00
|
|
|
debug_stack_usage_dec();
|
2012-07-12 01:26:35 +07:00
|
|
|
exit:
|
2015-07-04 02:44:32 +07:00
|
|
|
ist_exit(regs);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2014-04-17 15:18:14 +07:00
|
|
|
NOKPROBE_SYMBOL(do_int3);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2008-10-04 03:00:39 +07:00
|
|
|
#ifdef CONFIG_X86_64
|
2008-12-26 15:20:22 +07:00
|
|
|
/*
|
2014-11-12 03:49:41 +07:00
|
|
|
* Help handler running on IST stack to switch off the IST stack if the
|
|
|
|
* interrupted code was in user mode. The actual stack switch is done in
|
|
|
|
* entry_64.S
|
2008-12-26 15:20:22 +07:00
|
|
|
*/
|
2014-11-25 08:39:06 +07:00
|
|
|
asmlinkage __visible notrace struct pt_regs *sync_regs(struct pt_regs *eregs)
|
2008-10-04 03:00:39 +07:00
|
|
|
{
|
2014-11-12 03:49:41 +07:00
|
|
|
struct pt_regs *regs = task_pt_regs(current);
|
|
|
|
*regs = *eregs;
|
2008-10-04 03:00:39 +07:00
|
|
|
return regs;
|
|
|
|
}
|
2014-04-17 15:18:14 +07: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 09:00:33 +07:00
|
|
|
|
|
|
|
struct bad_iret_stack {
|
|
|
|
void *error_entry_ret;
|
|
|
|
struct pt_regs regs;
|
|
|
|
};
|
|
|
|
|
2014-11-25 08:39:06 +07: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 09:00:33 +07: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
|
|
|
|
* correctly, we want move our stack frame to task_pt_regs
|
|
|
|
* and we want to pretend that the exception came from the
|
|
|
|
* iret target.
|
|
|
|
*/
|
|
|
|
struct bad_iret_stack *new_stack =
|
|
|
|
container_of(task_pt_regs(current),
|
|
|
|
struct bad_iret_stack, regs);
|
|
|
|
|
|
|
|
/* 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 08:33:33 +07: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 09:00:33 +07:00
|
|
|
return new_stack;
|
|
|
|
}
|
2014-11-25 08:39:06 +07:00
|
|
|
NOKPROBE_SYMBOL(fixup_bad_iret);
|
2008-10-04 03:00:39 +07:00
|
|
|
#endif
|
|
|
|
|
2016-03-10 10:00:30 +07: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 05:20:36 +07: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 17:15:50 +07:00
|
|
|
*
|
2005-04-17 05:20:36 +07: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 04:17:11 +07:00
|
|
|
*
|
|
|
|
* May run on IST stack.
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
2014-04-17 15:18:14 +07:00
|
|
|
dotraplinkage void do_debug(struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
|
|
|
struct task_struct *tsk = current;
|
2010-06-30 20:09:06 +07:00
|
|
|
int user_icebp = 0;
|
2009-06-02 01:14:08 +07:00
|
|
|
unsigned long dr6;
|
2008-09-23 16:53:52 +07:00
|
|
|
int si_code;
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2015-07-04 02:44:32 +07:00
|
|
|
ist_enter(regs);
|
2014-06-14 13:47:12 +07:00
|
|
|
|
2009-06-02 01:14:08 +07:00
|
|
|
get_debugreg(dr6, 6);
|
2016-03-10 10:00:29 +07: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 05:20:36 +07:00
|
|
|
|
2010-01-28 18:14:01 +07:00
|
|
|
/* Filter out all the reserved bits which are preset to 1 */
|
|
|
|
dr6 &= ~DR6_RESERVED;
|
|
|
|
|
2016-03-10 10:00:28 +07: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 10:00:30 +07: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 20:09:06 +07: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 08:33:33 +07:00
|
|
|
if (!dr6 && user_mode(regs))
|
2010-06-30 20:09:06 +07:00
|
|
|
user_icebp = 1;
|
|
|
|
|
2016-03-10 10:00:30 +07:00
|
|
|
/* Catch kmemcheck conditions! */
|
2009-06-17 17:52:15 +07:00
|
|
|
if ((dr6 & DR_STEP) && kmemcheck_trap(regs))
|
2012-07-12 01:26:35 +07:00
|
|
|
goto exit;
|
2008-04-04 05:53:23 +07:00
|
|
|
|
2009-06-02 01:14:08 +07: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 15:17:33 +07:00
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_debug_handler(regs))
|
|
|
|
goto exit;
|
|
|
|
#endif
|
|
|
|
|
2013-06-16 11:42:47 +07:00
|
|
|
if (notify_die(DIE_DEBUG, "debug", regs, (long)&dr6, error_code,
|
2009-06-02 01:17:06 +07:00
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 01:26:35 +07:00
|
|
|
goto exit;
|
2008-09-30 23:41:37 +07:00
|
|
|
|
2011-12-16 23:43:02 +07: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 05:20:36 +07:00
|
|
|
/* It's safe to allow irq's after DR6 has been saved */
|
2016-01-26 02:41:46 +07:00
|
|
|
preempt_disable();
|
|
|
|
cond_local_irq_enable(regs);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2015-03-19 08:33:35 +07:00
|
|
|
if (v8086_mode(regs)) {
|
2012-03-10 07:07:10 +07:00
|
|
|
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
|
|
|
|
X86_TRAP_DB);
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_disable(regs);
|
|
|
|
preempt_enable_no_resched();
|
2011-12-16 23:43:02 +07:00
|
|
|
debug_stack_usage_dec();
|
2012-07-12 01:26:35 +07:00
|
|
|
goto exit;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2016-03-10 10:00:30 +07: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 01:14:08 +07:00
|
|
|
tsk->thread.debugreg6 &= ~DR_STEP;
|
|
|
|
set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
|
|
|
|
regs->flags &= ~X86_EFLAGS_TF;
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2009-06-02 01:14:08 +07:00
|
|
|
si_code = get_si_code(tsk->thread.debugreg6);
|
2010-06-30 20:09:06 +07:00
|
|
|
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
|
2009-06-02 01:14:08 +07:00
|
|
|
send_sigtrap(tsk, regs, error_code, si_code);
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_disable(regs);
|
|
|
|
preempt_enable_no_resched();
|
2011-12-16 23:43:02 +07:00
|
|
|
debug_stack_usage_dec();
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2012-07-12 01:26:35 +07:00
|
|
|
exit:
|
2016-03-10 10:00:33 +07:00
|
|
|
#if defined(CONFIG_X86_32)
|
|
|
|
/*
|
|
|
|
* This is the most likely code path that involves non-trivial use
|
|
|
|
* of the SYSENTER stack. Check that we haven't overrun it.
|
|
|
|
*/
|
|
|
|
WARN(this_cpu_read(cpu_tss.SYSENTER_stack_canary) != STACK_END_MAGIC,
|
|
|
|
"Overran or corrupted SYSENTER stack\n");
|
|
|
|
#endif
|
2015-07-04 02:44:32 +07:00
|
|
|
ist_exit(regs);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
2014-04-17 15:18:14 +07:00
|
|
|
NOKPROBE_SYMBOL(do_debug);
|
2005-04-17 05:20:36 +07: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 01:34:00 +07:00
|
|
|
static void math_error(struct pt_regs *regs, int error_code, int trapnr)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2010-03-21 20:00:45 +07:00
|
|
|
struct task_struct *task = current;
|
2015-04-30 14:29:38 +07:00
|
|
|
struct fpu *fpu = &task->thread.fpu;
|
2005-04-17 05:20:36 +07:00
|
|
|
siginfo_t info;
|
2012-03-10 07:07:10 +07:00
|
|
|
char *str = (trapnr == X86_TRAP_MF) ? "fpu exception" :
|
|
|
|
"simd exception";
|
2010-03-21 20:00:45 +07:00
|
|
|
|
|
|
|
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, SIGFPE) == NOTIFY_STOP)
|
|
|
|
return;
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_enable(regs);
|
2010-03-21 20:00:45 +07:00
|
|
|
|
2015-04-30 14:29:38 +07:00
|
|
|
if (!user_mode(regs)) {
|
2016-02-18 01:20:12 +07:00
|
|
|
if (!fixup_exception(regs, trapnr)) {
|
2010-03-21 20:00:45 +07:00
|
|
|
task->thread.error_code = error_code;
|
2012-03-12 16:25:55 +07:00
|
|
|
task->thread.trap_nr = trapnr;
|
2010-03-21 20:00:45 +07:00
|
|
|
die(str, regs, error_code);
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Save the info for the exception handler and clear the error.
|
|
|
|
*/
|
2015-04-30 14:29:38 +07:00
|
|
|
fpu__save(fpu);
|
|
|
|
|
|
|
|
task->thread.trap_nr = trapnr;
|
2010-03-21 20:00:44 +07:00
|
|
|
task->thread.error_code = error_code;
|
2015-04-30 14:29:38 +07:00
|
|
|
info.si_signo = SIGFPE;
|
|
|
|
info.si_errno = 0;
|
|
|
|
info.si_addr = (void __user *)uprobe_get_trap_addr(regs);
|
2008-12-23 08:56:05 +07:00
|
|
|
|
2015-04-30 14:29:38 +07:00
|
|
|
info.si_code = fpu__exception_code(fpu, trapnr);
|
2008-12-23 08:56:05 +07:00
|
|
|
|
2015-04-30 14:29:38 +07:00
|
|
|
/* Retry when we get spurious exceptions: */
|
|
|
|
if (!info.si_code)
|
2012-03-10 07:07:10 +07:00
|
|
|
return;
|
2015-04-30 14:29:38 +07:00
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
force_sig_info(SIGFPE, &info, task);
|
|
|
|
}
|
|
|
|
|
2008-09-30 23:41:36 +07:00
|
|
|
dotraplinkage void do_coprocessor_error(struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2012-03-10 07:07:10 +07:00
|
|
|
math_error(regs, error_code, X86_TRAP_MF);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2008-09-30 23:41:36 +07:00
|
|
|
dotraplinkage void
|
|
|
|
do_simd_coprocessor_error(struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2012-03-10 07:07:10 +07:00
|
|
|
math_error(regs, error_code, X86_TRAP_XF);
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|
|
|
|
|
2008-09-30 23:41:36 +07:00
|
|
|
dotraplinkage void
|
|
|
|
do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
|
2005-04-17 05:20:36 +07:00
|
|
|
{
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_enable(regs);
|
2008-10-04 03:00:39 +07:00
|
|
|
}
|
|
|
|
|
2014-04-17 15:18:14 +07:00
|
|
|
dotraplinkage void
|
2009-02-10 21:51:45 +07:00
|
|
|
do_device_not_available(struct pt_regs *regs, long error_code)
|
2008-09-10 02:56:02 +07:00
|
|
|
{
|
2016-11-01 05:18:47 +07:00
|
|
|
unsigned long cr0;
|
|
|
|
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2012-08-25 04:13:02 +07:00
|
|
|
|
2010-09-04 08:17:15 +07:00
|
|
|
#ifdef CONFIG_MATH_EMULATION
|
2016-01-25 05:38:09 +07:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_FPU) && (read_cr0() & X86_CR0_EM)) {
|
2009-02-09 20:17:39 +07:00
|
|
|
struct math_emu_info info = { };
|
|
|
|
|
2016-01-26 02:41:46 +07:00
|
|
|
cond_local_irq_enable(regs);
|
2009-02-09 20:17:39 +07:00
|
|
|
|
2009-02-10 21:51:45 +07:00
|
|
|
info.regs = regs;
|
2009-02-09 20:17:39 +07:00
|
|
|
math_emulate(&info);
|
2010-09-04 08:17:15 +07:00
|
|
|
return;
|
2008-09-10 02:56:02 +07:00
|
|
|
}
|
2010-09-04 08:17:15 +07:00
|
|
|
#endif
|
2016-11-01 05:18:47 +07:00
|
|
|
|
|
|
|
/* This should not happen. */
|
|
|
|
cr0 = read_cr0();
|
|
|
|
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 02:56:02 +07:00
|
|
|
}
|
2014-04-17 15:18:14 +07:00
|
|
|
NOKPROBE_SYMBOL(do_device_not_available);
|
2008-09-10 02:56:02 +07:00
|
|
|
|
2008-10-04 03:00:39 +07:00
|
|
|
#ifdef CONFIG_X86_32
|
2008-09-30 23:41:36 +07:00
|
|
|
dotraplinkage void do_iret_error(struct pt_regs *regs, long error_code)
|
2008-09-10 02:56:13 +07:00
|
|
|
{
|
|
|
|
siginfo_t info;
|
2012-07-12 01:26:35 +07:00
|
|
|
|
2015-09-01 22:40:25 +07:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2008-09-10 02:56:13 +07:00
|
|
|
local_irq_enable();
|
|
|
|
|
|
|
|
info.si_signo = SIGILL;
|
|
|
|
info.si_errno = 0;
|
|
|
|
info.si_code = ILL_BADSTK;
|
2009-02-22 07:00:57 +07:00
|
|
|
info.si_addr = NULL;
|
2012-03-10 07:07:10 +07:00
|
|
|
if (notify_die(DIE_TRAP, "iret exception", regs, error_code,
|
2012-07-12 01:26:35 +07:00
|
|
|
X86_TRAP_IRET, SIGILL) != NOTIFY_STOP) {
|
|
|
|
do_trap(X86_TRAP_IRET, SIGILL, "iret exception", regs, error_code,
|
|
|
|
&info);
|
|
|
|
}
|
2008-09-10 02:56:13 +07:00
|
|
|
}
|
2008-10-04 03:00:39 +07:00
|
|
|
#endif
|
2008-09-10 02:56:13 +07:00
|
|
|
|
2010-05-21 09:04:29 +07:00
|
|
|
/* Set of traps needed for early debugging. */
|
|
|
|
void __init early_trap_init(void)
|
|
|
|
{
|
2015-02-26 12:49:39 +07:00
|
|
|
/*
|
2015-02-27 11:19:49 +07:00
|
|
|
* Don't use IST to set DEBUG_STACK as it doesn't work until TSS
|
|
|
|
* is ready in cpu_init() <-- trap_init(). Before trap_init(),
|
|
|
|
* CPU runs at ring 0 so it is impossible to hit an invalid
|
|
|
|
* stack. Using the original stack works well enough at this
|
|
|
|
* early stage. DEBUG_STACK will be equipped after cpu_init() in
|
2015-02-26 12:49:39 +07:00
|
|
|
* trap_init().
|
2015-02-27 11:19:49 +07:00
|
|
|
*
|
|
|
|
* We don't need to set trace_idt_table like set_intr_gate(),
|
|
|
|
* since we don't have trace_debug and it will be reset to
|
|
|
|
* 'debug' in trap_init() by set_intr_gate_ist().
|
2015-02-26 12:49:39 +07:00
|
|
|
*/
|
2015-02-27 11:19:49 +07:00
|
|
|
set_intr_gate_notrace(X86_TRAP_DB, debug);
|
2010-05-21 09:04:29 +07:00
|
|
|
/* int3 can be called from all */
|
2015-02-27 11:19:49 +07:00
|
|
|
set_system_intr_gate(X86_TRAP_BP, &int3);
|
x86, 64bit: Use a #PF handler to materialize early mappings on demand
Linear mode (CR0.PG = 0) is mutually exclusive with 64-bit mode; all
64-bit code has to use page tables. This makes it awkward before we
have first set up properly all-covering page tables to access objects
that are outside the static kernel range.
So far we have dealt with that simply by mapping a fixed amount of
low memory, but that fails in at least two upcoming use cases:
1. We will support load and run kernel, struct boot_params, ramdisk,
command line, etc. above the 4 GiB mark.
2. need to access ramdisk early to get microcode to update that as
early possible.
We could use early_iomap to access them too, but it will make code to
messy and hard to be unified with 32 bit.
Hence, set up a #PF table and use a fixed number of buffers to set up
page tables on demand. If the buffers fill up then we simply flush
them and start over. These buffers are all in __initdata, so it does
not increase RAM usage at runtime.
Thus, with the help of the #PF handler, we can set the final kernel
mapping from blank, and switch to init_level4_pgt later.
During the switchover in head_64.S, before #PF handler is available,
we use three pages to handle kernel crossing 1G, 512G boundaries with
sharing page by playing games with page aliasing: the same page is
mapped twice in the higher-level tables with appropriate wraparound.
The kernel region itself will be properly mapped; other mappings may
be spurious.
early_make_pgtable is using kernel high mapping address to access pages
to set page table.
-v4: Add phys_base offset to make kexec happy, and add
init_mapping_kernel() - Yinghai
-v5: fix compiling with xen, and add back ident level3 and level2 for xen
also move back init_level4_pgt from BSS to DATA again.
because we have to clear it anyway. - Yinghai
-v6: switch to init_level4_pgt in init_mem_mapping. - Yinghai
-v7: remove not needed clear_page for init_level4_page
it is with fill 512,8,0 already in head_64.S - Yinghai
-v8: we need to keep that handler alive until init_mem_mapping and don't
let early_trap_init to trash that early #PF handler.
So split early_trap_pf_init out and move it down. - Yinghai
-v9: switchover only cover kernel space instead of 1G so could avoid
touch possible mem holes. - Yinghai
-v11: change far jmp back to far return to initial_code, that is needed
to fix failure that is reported by Konrad on AMD systems. - Yinghai
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1359058816-7615-12-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-01-25 03:19:52 +07:00
|
|
|
#ifdef CONFIG_X86_32
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_PF, page_fault);
|
x86, 64bit: Use a #PF handler to materialize early mappings on demand
Linear mode (CR0.PG = 0) is mutually exclusive with 64-bit mode; all
64-bit code has to use page tables. This makes it awkward before we
have first set up properly all-covering page tables to access objects
that are outside the static kernel range.
So far we have dealt with that simply by mapping a fixed amount of
low memory, but that fails in at least two upcoming use cases:
1. We will support load and run kernel, struct boot_params, ramdisk,
command line, etc. above the 4 GiB mark.
2. need to access ramdisk early to get microcode to update that as
early possible.
We could use early_iomap to access them too, but it will make code to
messy and hard to be unified with 32 bit.
Hence, set up a #PF table and use a fixed number of buffers to set up
page tables on demand. If the buffers fill up then we simply flush
them and start over. These buffers are all in __initdata, so it does
not increase RAM usage at runtime.
Thus, with the help of the #PF handler, we can set the final kernel
mapping from blank, and switch to init_level4_pgt later.
During the switchover in head_64.S, before #PF handler is available,
we use three pages to handle kernel crossing 1G, 512G boundaries with
sharing page by playing games with page aliasing: the same page is
mapped twice in the higher-level tables with appropriate wraparound.
The kernel region itself will be properly mapped; other mappings may
be spurious.
early_make_pgtable is using kernel high mapping address to access pages
to set page table.
-v4: Add phys_base offset to make kexec happy, and add
init_mapping_kernel() - Yinghai
-v5: fix compiling with xen, and add back ident level3 and level2 for xen
also move back init_level4_pgt from BSS to DATA again.
because we have to clear it anyway. - Yinghai
-v6: switch to init_level4_pgt in init_mem_mapping. - Yinghai
-v7: remove not needed clear_page for init_level4_page
it is with fill 512,8,0 already in head_64.S - Yinghai
-v8: we need to keep that handler alive until init_mem_mapping and don't
let early_trap_init to trash that early #PF handler.
So split early_trap_pf_init out and move it down. - Yinghai
-v9: switchover only cover kernel space instead of 1G so could avoid
touch possible mem holes. - Yinghai
-v11: change far jmp back to far return to initial_code, that is needed
to fix failure that is reported by Konrad on AMD systems. - Yinghai
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1359058816-7615-12-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-01-25 03:19:52 +07:00
|
|
|
#endif
|
2010-05-21 09:04:29 +07:00
|
|
|
load_idt(&idt_descr);
|
|
|
|
}
|
|
|
|
|
x86, 64bit: Use a #PF handler to materialize early mappings on demand
Linear mode (CR0.PG = 0) is mutually exclusive with 64-bit mode; all
64-bit code has to use page tables. This makes it awkward before we
have first set up properly all-covering page tables to access objects
that are outside the static kernel range.
So far we have dealt with that simply by mapping a fixed amount of
low memory, but that fails in at least two upcoming use cases:
1. We will support load and run kernel, struct boot_params, ramdisk,
command line, etc. above the 4 GiB mark.
2. need to access ramdisk early to get microcode to update that as
early possible.
We could use early_iomap to access them too, but it will make code to
messy and hard to be unified with 32 bit.
Hence, set up a #PF table and use a fixed number of buffers to set up
page tables on demand. If the buffers fill up then we simply flush
them and start over. These buffers are all in __initdata, so it does
not increase RAM usage at runtime.
Thus, with the help of the #PF handler, we can set the final kernel
mapping from blank, and switch to init_level4_pgt later.
During the switchover in head_64.S, before #PF handler is available,
we use three pages to handle kernel crossing 1G, 512G boundaries with
sharing page by playing games with page aliasing: the same page is
mapped twice in the higher-level tables with appropriate wraparound.
The kernel region itself will be properly mapped; other mappings may
be spurious.
early_make_pgtable is using kernel high mapping address to access pages
to set page table.
-v4: Add phys_base offset to make kexec happy, and add
init_mapping_kernel() - Yinghai
-v5: fix compiling with xen, and add back ident level3 and level2 for xen
also move back init_level4_pgt from BSS to DATA again.
because we have to clear it anyway. - Yinghai
-v6: switch to init_level4_pgt in init_mem_mapping. - Yinghai
-v7: remove not needed clear_page for init_level4_page
it is with fill 512,8,0 already in head_64.S - Yinghai
-v8: we need to keep that handler alive until init_mem_mapping and don't
let early_trap_init to trash that early #PF handler.
So split early_trap_pf_init out and move it down. - Yinghai
-v9: switchover only cover kernel space instead of 1G so could avoid
touch possible mem holes. - Yinghai
-v11: change far jmp back to far return to initial_code, that is needed
to fix failure that is reported by Konrad on AMD systems. - Yinghai
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1359058816-7615-12-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-01-25 03:19:52 +07:00
|
|
|
void __init early_trap_pf_init(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_X86_64
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_PF, page_fault);
|
x86, 64bit: Use a #PF handler to materialize early mappings on demand
Linear mode (CR0.PG = 0) is mutually exclusive with 64-bit mode; all
64-bit code has to use page tables. This makes it awkward before we
have first set up properly all-covering page tables to access objects
that are outside the static kernel range.
So far we have dealt with that simply by mapping a fixed amount of
low memory, but that fails in at least two upcoming use cases:
1. We will support load and run kernel, struct boot_params, ramdisk,
command line, etc. above the 4 GiB mark.
2. need to access ramdisk early to get microcode to update that as
early possible.
We could use early_iomap to access them too, but it will make code to
messy and hard to be unified with 32 bit.
Hence, set up a #PF table and use a fixed number of buffers to set up
page tables on demand. If the buffers fill up then we simply flush
them and start over. These buffers are all in __initdata, so it does
not increase RAM usage at runtime.
Thus, with the help of the #PF handler, we can set the final kernel
mapping from blank, and switch to init_level4_pgt later.
During the switchover in head_64.S, before #PF handler is available,
we use three pages to handle kernel crossing 1G, 512G boundaries with
sharing page by playing games with page aliasing: the same page is
mapped twice in the higher-level tables with appropriate wraparound.
The kernel region itself will be properly mapped; other mappings may
be spurious.
early_make_pgtable is using kernel high mapping address to access pages
to set page table.
-v4: Add phys_base offset to make kexec happy, and add
init_mapping_kernel() - Yinghai
-v5: fix compiling with xen, and add back ident level3 and level2 for xen
also move back init_level4_pgt from BSS to DATA again.
because we have to clear it anyway. - Yinghai
-v6: switch to init_level4_pgt in init_mem_mapping. - Yinghai
-v7: remove not needed clear_page for init_level4_page
it is with fill 512,8,0 already in head_64.S - Yinghai
-v8: we need to keep that handler alive until init_mem_mapping and don't
let early_trap_init to trash that early #PF handler.
So split early_trap_pf_init out and move it down. - Yinghai
-v9: switchover only cover kernel space instead of 1G so could avoid
touch possible mem holes. - Yinghai
-v11: change far jmp back to far return to initial_code, that is needed
to fix failure that is reported by Konrad on AMD systems. - Yinghai
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1359058816-7615-12-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-01-25 03:19:52 +07:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
void __init trap_init(void)
|
|
|
|
{
|
2007-10-20 01:35:03 +07:00
|
|
|
int i;
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
#ifdef CONFIG_EISA
|
2008-01-30 19:33:49 +07:00
|
|
|
void __iomem *p = early_ioremap(0x0FFFD9, 4);
|
2008-02-26 17:15:50 +07:00
|
|
|
|
|
|
|
if (readl(p) == 'E' + ('I'<<8) + ('S'<<16) + ('A'<<24))
|
2005-04-17 05:20:36 +07:00
|
|
|
EISA_bus = 1;
|
2008-01-30 19:33:49 +07:00
|
|
|
early_iounmap(p, 4);
|
2005-04-17 05:20:36 +07:00
|
|
|
#endif
|
|
|
|
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_DE, divide_error);
|
2012-03-10 07:07:10 +07:00
|
|
|
set_intr_gate_ist(X86_TRAP_NMI, &nmi, NMI_STACK);
|
2008-10-04 03:00:32 +07:00
|
|
|
/* int4 can be called from all */
|
2012-03-10 07:07:10 +07:00
|
|
|
set_system_intr_gate(X86_TRAP_OF, &overflow);
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_BR, bounds);
|
|
|
|
set_intr_gate(X86_TRAP_UD, invalid_op);
|
|
|
|
set_intr_gate(X86_TRAP_NM, device_not_available);
|
2008-10-04 03:00:39 +07:00
|
|
|
#ifdef CONFIG_X86_32
|
2012-03-10 07:07:10 +07:00
|
|
|
set_task_gate(X86_TRAP_DF, GDT_ENTRY_DOUBLEFAULT_TSS);
|
2008-10-04 03:00:39 +07:00
|
|
|
#else
|
2012-03-10 07:07:10 +07:00
|
|
|
set_intr_gate_ist(X86_TRAP_DF, &double_fault, DOUBLEFAULT_STACK);
|
2008-10-04 03:00:39 +07:00
|
|
|
#endif
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_OLD_MF, coprocessor_segment_overrun);
|
|
|
|
set_intr_gate(X86_TRAP_TS, invalid_TSS);
|
|
|
|
set_intr_gate(X86_TRAP_NP, segment_not_present);
|
2014-11-23 09:00:32 +07:00
|
|
|
set_intr_gate(X86_TRAP_SS, stack_segment);
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_GP, general_protection);
|
|
|
|
set_intr_gate(X86_TRAP_SPURIOUS, spurious_interrupt_bug);
|
|
|
|
set_intr_gate(X86_TRAP_MF, coprocessor_error);
|
|
|
|
set_intr_gate(X86_TRAP_AC, alignment_check);
|
2005-04-17 05:20:36 +07:00
|
|
|
#ifdef CONFIG_X86_MCE
|
2012-03-10 07:07:10 +07:00
|
|
|
set_intr_gate_ist(X86_TRAP_MC, &machine_check, MCE_STACK);
|
2005-04-17 05:20:36 +07:00
|
|
|
#endif
|
2013-10-31 03:37:00 +07:00
|
|
|
set_intr_gate(X86_TRAP_XF, simd_coprocessor_error);
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2009-01-25 17:38:09 +07:00
|
|
|
/* Reserve all the builtin and the syscall vector: */
|
|
|
|
for (i = 0; i < FIRST_EXTERNAL_VECTOR; i++)
|
|
|
|
set_bit(i, used_vectors);
|
|
|
|
|
2008-10-04 03:00:39 +07:00
|
|
|
#ifdef CONFIG_IA32_EMULATION
|
2015-06-08 13:28:07 +07:00
|
|
|
set_system_intr_gate(IA32_SYSCALL_VECTOR, entry_INT80_compat);
|
2009-01-25 17:38:09 +07:00
|
|
|
set_bit(IA32_SYSCALL_VECTOR, used_vectors);
|
2008-10-04 03:00:39 +07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_32
|
2016-03-10 04:24:32 +07:00
|
|
|
set_system_intr_gate(IA32_SYSCALL_VECTOR, entry_INT80_32);
|
2015-05-09 22:36:52 +07:00
|
|
|
set_bit(IA32_SYSCALL_VECTOR, used_vectors);
|
2008-10-04 03:00:39 +07:00
|
|
|
#endif
|
2009-01-25 17:38:09 +07:00
|
|
|
|
2013-04-11 02:24:22 +07: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() */
|
|
|
|
__set_fixmap(FIX_RO_IDT, __pa_symbol(idt_table), PAGE_KERNEL_RO);
|
|
|
|
idt_descr.address = fix_to_virt(FIX_RO_IDT);
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
/*
|
2008-02-26 17:15:50 +07:00
|
|
|
* Should be a barrier for any external CPU state:
|
2005-04-17 05:20:36 +07:00
|
|
|
*/
|
|
|
|
cpu_init();
|
|
|
|
|
2015-02-26 12:49:39 +07:00
|
|
|
/*
|
|
|
|
* X86_TRAP_DB and X86_TRAP_BP have been set
|
2015-02-27 11:19:49 +07:00
|
|
|
* in early_trap_init(). However, ITS works only after
|
2015-02-26 12:49:39 +07:00
|
|
|
* cpu_init() loads TSS. See comments in early_trap_init().
|
|
|
|
*/
|
|
|
|
set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK);
|
|
|
|
/* int3 can be called from all */
|
|
|
|
set_system_intr_gate_ist(X86_TRAP_BP, &int3, DEBUG_STACK);
|
|
|
|
|
2009-08-20 15:35:46 +07:00
|
|
|
x86_init.irqs.trap_init();
|
2011-12-09 15:02:19 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
2013-06-20 22:45:44 +07:00
|
|
|
memcpy(&debug_idt_table, &idt_table, IDT_ENTRIES * 16);
|
2012-03-10 07:07:10 +07:00
|
|
|
set_nmi_gate(X86_TRAP_DB, &debug);
|
|
|
|
set_nmi_gate(X86_TRAP_BP, &int3);
|
2011-12-09 15:02:19 +07:00
|
|
|
#endif
|
2005-04-17 05:20:36 +07:00
|
|
|
}
|