2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 1991, 1992 Linus Torvalds
|
2008-07-02 07:29:44 +08:00
|
|
|
* Copyright (C) 2000, 2001, 2002 Andi Kleen, SuSE Labs
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Pentium III FXSR, SSE support
|
|
|
|
* Gareth Hughes <gareth@valinux.com>, May 2000
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2008-10-04 05:17:11 +08:00
|
|
|
* Handle hardware traps and faults.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2012-05-22 10:50:07 +08:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2013-02-24 07:23:25 +08:00
|
|
|
#include <linux/context_tracking.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/interrupt.h>
|
|
|
|
#include <linux/kallsyms.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/kprobes.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/kdebug.h>
|
2010-05-21 10:04:25 +08:00
|
|
|
#include <linux/kgdb.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/kernel.h>
|
2016-07-14 08:18:56 +08:00
|
|
|
#include <linux/export.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/ptrace.h>
|
uprobes/x86: Fix the wrong ->si_addr when xol triggers a trap
If the probed insn triggers a trap, ->si_addr = regs->ip is technically
correct, but this is not what the signal handler wants; we need to pass
the address of the probed insn, not the address of xol slot.
Add the new arch-agnostic helper, uprobe_get_trap_addr(), and change
fill_trap_info() and math_error() to use it. !CONFIG_UPROBES case in
uprobes.h uses a macro to avoid include hell and ensure that it can be
compiled even if an architecture doesn't define instruction_pointer().
Test-case:
#include <signal.h>
#include <stdio.h>
#include <unistd.h>
extern void probe_div(void);
void sigh(int sig, siginfo_t *info, void *c)
{
int passed = (info->si_addr == probe_div);
printf(passed ? "PASS\n" : "FAIL\n");
_exit(!passed);
}
int main(void)
{
struct sigaction sa = {
.sa_sigaction = sigh,
.sa_flags = SA_SIGINFO,
};
sigaction(SIGFPE, &sa, NULL);
asm (
"xor %ecx,%ecx\n"
".globl probe_div; probe_div:\n"
"idiv %ecx\n"
);
return 0;
}
it fails if probe_div() is probed.
Note: show_unhandled_signals users should probably use this helper too,
but we need to cleanup them first.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
2014-05-13 00:24:45 +08:00
|
|
|
#include <linux/uprobes.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/string.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/delay.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/errno.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/kexec.h>
|
|
|
|
#include <linux/sched.h>
|
2017-02-09 01:51:37 +08:00
|
|
|
#include <linux/sched/task_stack.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/timer.h>
|
|
|
|
#include <linux/init.h>
|
2006-12-08 18:36:21 +08:00
|
|
|
#include <linux/bug.h>
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <linux/nmi.h>
|
|
|
|
#include <linux/mm.h>
|
2008-10-04 05:17:11 +08:00
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/io.h>
|
2020-02-19 16:46:43 +08:00
|
|
|
#include <linux/hardirq.h>
|
|
|
|
#include <linux/atomic.h>
|
|
|
|
|
2008-02-26 18:15:50 +08:00
|
|
|
#include <asm/stacktrace.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/debugreg.h>
|
2016-04-27 03:23:24 +08:00
|
|
|
#include <asm/text-patching.h>
|
2011-08-16 21:57:10 +08:00
|
|
|
#include <asm/ftrace.h>
|
2008-10-04 05:17:11 +08:00
|
|
|
#include <asm/traps.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/desc.h>
|
2015-04-24 08:54:44 +08:00
|
|
|
#include <asm/fpu/internal.h>
|
2020-01-27 04:05:35 +08:00
|
|
|
#include <asm/cpu.h>
|
2017-12-21 01:28:54 +08:00
|
|
|
#include <asm/cpu_entry_area.h>
|
2009-06-15 16:22:15 +08:00
|
|
|
#include <asm/mce.h>
|
2013-04-11 03:24:22 +08:00
|
|
|
#include <asm/fixmap.h>
|
2009-01-29 02:34:09 +08:00
|
|
|
#include <asm/mach_traps.h>
|
2013-07-23 16:09:28 +08:00
|
|
|
#include <asm/alternative.h>
|
2015-06-08 02:37:01 +08:00
|
|
|
#include <asm/fpu/xstate.h>
|
2015-07-29 13:41:21 +08:00
|
|
|
#include <asm/vm86.h>
|
2017-11-06 10:27:55 +08:00
|
|
|
#include <asm/umip.h>
|
x86/traps: Print address on #GP
A frequent cause of #GP exceptions are memory accesses to non-canonical
addresses. Unlike #PF, #GP doesn't report a fault address in CR2, so the
kernel doesn't currently print the fault address for a #GP.
Luckily, the necessary infrastructure for decoding x86 instructions and
computing the memory address being accessed is already present. Hook
it up to the #GP handler so that the address operand of the faulting
instruction can be figured out and printed.
Distinguish two cases:
a) (Part of) the memory range being accessed lies in the non-canonical
address range; in this case, it is likely that the decoded address
is actually the one that caused the #GP.
b) The entire memory range of the decoded operand lies in canonical
address space; the #GP may or may not be related in some way to the
computed address. Print it, but with hedging language in the message.
While it is already possible to compute the faulting address manually by
disassembling the opcode dump and evaluating the instruction against the
register dump, this should make it slightly easier to identify crashes
at a glance.
Note that the operand length which comes from the instruction decoder
and is used to determine whether the access straddles into non-canonical
address space, is currently somewhat unreliable; but it should be good
enough, considering that Linux on x86-64 never maps the page directly
before the start of the non-canonical range anyway, and therefore the
case where a memory range begins in that page and potentially straddles
into the non-canonical range should be fairly uncommon.
In the case the address is still computed wrongly, it only influences
whether the error message claims that the access is canonical.
[ bp: Remove ambiguous "we", massage, reflow comments and spacing. ]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: kasan-dev@googlegroups.com
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191218231150.12139-2-jannh@google.com
2019-12-19 07:11:48 +08:00
|
|
|
#include <asm/insn.h>
|
|
|
|
#include <asm/insn-eval.h>
|
2008-10-04 05:17:11 +08:00
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
2009-08-20 16:35:46 +08:00
|
|
|
#include <asm/x86_init.h>
|
2008-10-04 04:00:39 +08:00
|
|
|
#include <asm/pgalloc.h>
|
|
|
|
#include <asm/proto.h>
|
|
|
|
#else
|
2008-10-04 05:17:11 +08:00
|
|
|
#include <asm/processor-flags.h>
|
2009-02-23 07:34:39 +08:00
|
|
|
#include <asm/setup.h>
|
2015-06-08 14:42:03 +08:00
|
|
|
#include <asm/proto.h>
|
2008-10-04 04:00:39 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-09-14 05:29:26 +08:00
|
|
|
DECLARE_BITMAP(system_vectors, NR_VECTORS);
|
2008-12-20 07:23:44 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
static inline void cond_local_irq_enable(struct pt_regs *regs)
|
2008-09-10 03:55:55 +08:00
|
|
|
{
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
local_irq_enable();
|
|
|
|
}
|
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
static inline void cond_local_irq_disable(struct pt_regs *regs)
|
2008-10-01 00:41:37 +08:00
|
|
|
{
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
local_irq_disable();
|
|
|
|
}
|
|
|
|
|
2017-02-02 21:43:51 +08:00
|
|
|
int is_valid_bugaddr(unsigned long addr)
|
|
|
|
{
|
|
|
|
unsigned short ud;
|
|
|
|
|
|
|
|
if (addr < TASK_SIZE_MAX)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (probe_kernel_address((unsigned short *)addr, ud))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return ud == INSN_UD0 || ud == INSN_UD2;
|
|
|
|
}
|
|
|
|
|
2017-06-12 19:52:46 +08:00
|
|
|
int fixup_bug(struct pt_regs *regs, int trapnr)
|
2017-02-02 21:43:51 +08:00
|
|
|
{
|
|
|
|
if (trapnr != X86_TRAP_UD)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
switch (report_bug(regs->ip, regs)) {
|
|
|
|
case BUG_TRAP_TYPE_NONE:
|
|
|
|
case BUG_TRAP_TYPE_BUG:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case BUG_TRAP_TYPE_WARN:
|
2018-02-09 20:16:59 +08:00
|
|
|
regs->ip += LEN_UD2;
|
2017-02-02 21:43:51 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
static nokprobe_inline int
|
2017-08-05 03:01:50 +08:00
|
|
|
do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
|
2012-09-25 20:51:19 +08:00
|
|
|
struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2015-03-19 09:33:35 +08:00
|
|
|
if (v8086_mode(regs)) {
|
2008-09-26 20:03:08 +08:00
|
|
|
/*
|
2012-09-25 20:51:19 +08:00
|
|
|
* Traps 0, 1, 3, 4, and 5 should be forwarded to vm86.
|
2008-09-26 20:03:08 +08:00
|
|
|
* On nmi (interrupt 2), do_trap should not be called.
|
|
|
|
*/
|
2012-09-25 20:51:19 +08:00
|
|
|
if (trapnr < X86_TRAP_UD) {
|
|
|
|
if (!handle_vm86_trap((struct kernel_vm86_regs *) regs,
|
|
|
|
error_code, trapnr))
|
|
|
|
return 0;
|
|
|
|
}
|
2017-08-05 03:01:50 +08:00
|
|
|
} else if (!user_mode(regs)) {
|
2018-08-29 04:14:19 +08:00
|
|
|
if (fixup_exception(regs, trapnr, error_code, 0))
|
2017-02-02 21:43:51 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
|
|
|
tsk->thread.trap_nr = trapnr;
|
|
|
|
die(str, regs, error_code);
|
2012-09-25 20:51:19 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-02-26 18:15:50 +08:00
|
|
|
/*
|
2012-03-12 17:25:55 +08:00
|
|
|
* We want error_code and trap_nr set for userspace faults and
|
2008-02-26 18:15:50 +08:00
|
|
|
* kernelspace faults which result in die(), but not
|
|
|
|
* kernelspace faults which are fixed up. die() gives the
|
|
|
|
* process no chance to handle the signal and notice the
|
|
|
|
* kernel fault information, so that won't result in polluting
|
|
|
|
* the information about previously queued, but not yet
|
2020-02-26 06:16:25 +08:00
|
|
|
* delivered, faults. See also exc_general_protection below.
|
2008-02-26 18:15:50 +08:00
|
|
|
*/
|
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 17:25:55 +08:00
|
|
|
tsk->thread.trap_nr = trapnr;
|
2007-05-03 01:27:05 +08:00
|
|
|
|
2012-09-25 20:51:19 +08:00
|
|
|
return -1;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-08-04 03:34:24 +08:00
|
|
|
static void show_signal(struct task_struct *tsk, int signr,
|
|
|
|
const char *type, const char *desc,
|
|
|
|
struct pt_regs *regs, long error_code)
|
|
|
|
{
|
2008-10-04 04:00:39 +08:00
|
|
|
if (show_unhandled_signals && unhandled_signal(tsk, signr) &&
|
|
|
|
printk_ratelimit()) {
|
2017-08-04 03:34:24 +08:00
|
|
|
pr_info("%s[%d] %s%s ip:%lx sp:%lx error:%lx",
|
|
|
|
tsk->comm, task_pid_nr(tsk), type, desc,
|
2012-05-22 10:50:07 +08:00
|
|
|
regs->ip, regs->sp, error_code);
|
2017-04-07 20:09:04 +08:00
|
|
|
print_vma_addr(KERN_CONT " in ", regs->ip);
|
2012-05-22 10:50:07 +08:00
|
|
|
pr_cont("\n");
|
2008-10-04 04:00:39 +08:00
|
|
|
}
|
2017-08-04 03:34:24 +08:00
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
static void
|
2012-09-25 20:51:19 +08:00
|
|
|
do_trap(int trapnr, int signr, char *str, struct pt_regs *regs,
|
2018-04-17 03:29:39 +08:00
|
|
|
long error_code, int sicode, void __user *addr)
|
2012-09-25 20:51:19 +08:00
|
|
|
{
|
|
|
|
struct task_struct *tsk = current;
|
|
|
|
|
|
|
|
if (!do_trap_no_signal(tsk, trapnr, str, regs, error_code))
|
|
|
|
return;
|
2007-05-03 01:27:05 +08:00
|
|
|
|
2017-08-04 03:34:24 +08:00
|
|
|
show_signal(tsk, signr, "trap ", str, regs, error_code);
|
2008-10-04 04:00:39 +08:00
|
|
|
|
2018-04-17 03:29:39 +08:00
|
|
|
if (!sicode)
|
2019-05-23 23:17:27 +08:00
|
|
|
force_sig(signr);
|
2018-04-17 03:29:39 +08:00
|
|
|
else
|
2019-05-24 00:04:24 +08:00
|
|
|
force_sig_fault(signr, sicode, addr);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_trap);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-05-07 23:21:34 +08:00
|
|
|
static void do_error_trap(struct pt_regs *regs, long error_code, char *str,
|
2018-04-17 03:29:39 +08:00
|
|
|
unsigned long trapnr, int signr, int sicode, void __user *addr)
|
2014-05-07 23:21:34 +08:00
|
|
|
{
|
2015-09-01 23:40:25 +08:00
|
|
|
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
|
2015-07-04 03:44:24 +08:00
|
|
|
|
2017-07-24 18:04:28 +08:00
|
|
|
/*
|
|
|
|
* WARN*()s end up here; fix them up before we call the
|
|
|
|
* notifier chain.
|
|
|
|
*/
|
|
|
|
if (!user_mode(regs) && fixup_bug(regs, trapnr))
|
|
|
|
return;
|
|
|
|
|
2014-05-07 23:21:34 +08:00
|
|
|
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
|
|
|
|
NOTIFY_STOP) {
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2018-04-17 03:29:39 +08:00
|
|
|
do_trap(trapnr, signr, str, regs, error_code, sicode, addr);
|
2019-10-23 20:27:10 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2014-05-07 23:21:34 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:13 +08:00
|
|
|
/*
|
|
|
|
* Posix requires to provide the address of the faulting instruction for
|
|
|
|
* SIGILL (#UD) and SIGFPE (#DE) in the si_addr member of siginfo_t.
|
|
|
|
*
|
|
|
|
* This address is usually regs->ip, but when an uprobe moved the code out
|
|
|
|
* of line then regs->ip points to the XOL code which would confuse
|
|
|
|
* anything which analyzes the fault address vs. the unmodified binary. If
|
|
|
|
* a trap happened in XOL code then uprobe maps regs->ip back to the
|
|
|
|
* original instruction address.
|
|
|
|
*/
|
|
|
|
static __always_inline void __user *error_get_trap_addr(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
return (void __user *)uprobe_get_trap_addr(regs);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:14 +08:00
|
|
|
DEFINE_IDTENTRY(exc_divide_error)
|
|
|
|
{
|
|
|
|
do_error_trap(regs, 0, "divide_error", X86_TRAP_DE, SIGFPE,
|
|
|
|
FPE_INTDIV, error_get_trap_addr(regs));
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:15 +08:00
|
|
|
DEFINE_IDTENTRY(exc_overflow)
|
|
|
|
{
|
|
|
|
do_error_trap(regs, 0, "overflow", X86_TRAP_OF, SIGSEGV, 0, NULL);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:18 +08:00
|
|
|
#ifdef CONFIG_X86_F00F_BUG
|
|
|
|
void handle_invalid_op(struct pt_regs *regs)
|
|
|
|
#else
|
|
|
|
static inline void handle_invalid_op(struct pt_regs *regs)
|
|
|
|
#endif
|
|
|
|
{
|
|
|
|
do_error_trap(regs, 0, "invalid opcode", X86_TRAP_UD, SIGILL,
|
|
|
|
ILL_ILLOPN, error_get_trap_addr(regs));
|
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_IDTENTRY(exc_invalid_op)
|
|
|
|
{
|
|
|
|
handle_invalid_op(regs);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:20 +08:00
|
|
|
DEFINE_IDTENTRY(exc_coproc_segment_overrun)
|
|
|
|
{
|
|
|
|
do_error_trap(regs, 0, "coprocessor segment overrun",
|
|
|
|
X86_TRAP_OLD_MF, SIGFPE, 0, NULL);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:22 +08:00
|
|
|
DEFINE_IDTENTRY_ERRORCODE(exc_invalid_tss)
|
|
|
|
{
|
|
|
|
do_error_trap(regs, error_code, "invalid TSS", X86_TRAP_TS, SIGSEGV,
|
|
|
|
0, NULL);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:23 +08:00
|
|
|
DEFINE_IDTENTRY_ERRORCODE(exc_segment_not_present)
|
|
|
|
{
|
|
|
|
do_error_trap(regs, error_code, "segment not present", X86_TRAP_NP,
|
|
|
|
SIGBUS, 0, NULL);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:24 +08:00
|
|
|
DEFINE_IDTENTRY_ERRORCODE(exc_stack_segment)
|
|
|
|
{
|
|
|
|
do_error_trap(regs, error_code, "stack segment", X86_TRAP_SS, SIGBUS,
|
|
|
|
0, NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:28 +08:00
|
|
|
DEFINE_IDTENTRY_ERRORCODE(exc_alignment_check)
|
2020-01-27 04:05:35 +08:00
|
|
|
{
|
|
|
|
char *str = "alignment check";
|
|
|
|
|
|
|
|
if (notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_AC, SIGBUS) == NOTIFY_STOP)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!user_mode(regs))
|
|
|
|
die("Split lock detected\n", regs, error_code);
|
|
|
|
|
|
|
|
local_irq_enable();
|
|
|
|
|
|
|
|
if (handle_user_split_lock(regs, error_code))
|
|
|
|
return;
|
|
|
|
|
|
|
|
do_trap(X86_TRAP_AC, SIGBUS, "alignment check", regs,
|
|
|
|
error_code, BUS_ADRALN, NULL);
|
|
|
|
}
|
|
|
|
|
2016-08-11 17:35:23 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
2016-08-31 08:27:57 +08:00
|
|
|
__visible void __noreturn handle_stack_overflow(const char *message,
|
|
|
|
struct pt_regs *regs,
|
|
|
|
unsigned long fault_address)
|
2016-08-11 17:35:23 +08:00
|
|
|
{
|
|
|
|
printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is %p..%p)\n",
|
|
|
|
(void *)fault_address, current->stack,
|
|
|
|
(char *)current->stack + THREAD_SIZE - 1);
|
|
|
|
die(message, regs, 0);
|
|
|
|
|
|
|
|
/* Be absolutely certain we don't return. */
|
2018-10-27 06:20:04 +08:00
|
|
|
panic("%s", message);
|
2016-08-11 17:35:23 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-11-21 15:06:41 +08:00
|
|
|
/*
|
|
|
|
* Runs on an IST stack for x86_64 and on a special task stack for x86_32.
|
|
|
|
*
|
|
|
|
* On x86_64, this is more or less a normal kernel entry. Notwithstanding the
|
|
|
|
* SDM's warnings about double faults being unrecoverable, returning works as
|
|
|
|
* expected. Presumably what the SDM actually means is that the CPU may get
|
|
|
|
* the register state wrong on entry, so returning could be a bad idea.
|
|
|
|
*
|
|
|
|
* Various CPU engineers have promised that double faults due to an IRET fault
|
|
|
|
* while the stack is read-only are, in fact, recoverable.
|
|
|
|
*
|
|
|
|
* On x86_32, this is entered through a task gate, and regs are synthesized
|
|
|
|
* from the TSS. Returning is, in principle, okay, but changes to regs will
|
|
|
|
* be lost. If, for some reason, we need to return to a context with modified
|
|
|
|
* regs, the shim code could be adjusted to synchronize the registers.
|
|
|
|
*/
|
2019-07-11 19:40:59 +08:00
|
|
|
dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code, unsigned long cr2)
|
2008-10-04 04:00:39 +08:00
|
|
|
{
|
|
|
|
static const char str[] = "double fault";
|
|
|
|
struct task_struct *tsk = current;
|
|
|
|
|
2014-11-23 10:00:31 +08:00
|
|
|
#ifdef CONFIG_X86_ESPFIX64
|
|
|
|
extern unsigned char native_irq_return_iret[];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If IRET takes a non-IST fault on the espfix64 stack, then we
|
2017-12-04 22:07:22 +08:00
|
|
|
* end up promoting it to a doublefault. In that case, take
|
|
|
|
* advantage of the fact that we're not using the normal (TSS.sp0)
|
|
|
|
* stack right now. We can write a fake #GP(0) frame at TSS.sp0
|
|
|
|
* and then modify our own IRET frame so that, when we return,
|
|
|
|
* we land directly at the #GP(0) vector with the stack already
|
|
|
|
* set up according to its expectations.
|
|
|
|
*
|
|
|
|
* The net result is that our #GP handler will think that we
|
|
|
|
* entered from usermode with the bad user context.
|
2014-11-20 09:41:09 +08:00
|
|
|
*
|
2020-02-19 16:46:43 +08:00
|
|
|
* No need for nmi_enter() here because we don't use RCU.
|
2014-11-23 10:00:31 +08:00
|
|
|
*/
|
2017-12-12 23:56:36 +08:00
|
|
|
if (((long)regs->sp >> P4D_SHIFT) == ESPFIX_PGD_ENTRY &&
|
2014-11-23 10:00:31 +08:00
|
|
|
regs->cs == __KERNEL_CS &&
|
|
|
|
regs->ip == (unsigned long)native_irq_return_iret)
|
|
|
|
{
|
2017-12-04 22:07:29 +08:00
|
|
|
struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
|
2020-02-20 20:17:27 +08:00
|
|
|
unsigned long *p = (unsigned long *)regs->sp;
|
2014-11-23 10:00:31 +08:00
|
|
|
|
2017-12-04 22:07:22 +08:00
|
|
|
/*
|
|
|
|
* regs->sp points to the failing IRET frame on the
|
|
|
|
* ESPFIX64 stack. Copy it to the entry stack. This fills
|
|
|
|
* in gpregs->ss through gpregs->ip.
|
|
|
|
*
|
|
|
|
*/
|
2020-02-20 20:17:27 +08:00
|
|
|
gpregs->ip = p[0];
|
|
|
|
gpregs->cs = p[1];
|
|
|
|
gpregs->flags = p[2];
|
|
|
|
gpregs->sp = p[3];
|
|
|
|
gpregs->ss = p[4];
|
2017-12-04 22:07:22 +08:00
|
|
|
gpregs->orig_ax = 0; /* Missing (lost) #GP error code */
|
2014-11-23 10:00:31 +08:00
|
|
|
|
2017-12-04 22:07:22 +08:00
|
|
|
/*
|
|
|
|
* Adjust our frame so that we return straight to the #GP
|
|
|
|
* vector with the expected RSP value. This is safe because
|
|
|
|
* we won't enable interupts or schedule before we invoke
|
|
|
|
* general_protection, so nothing will clobber the stack
|
|
|
|
* frame we just set up.
|
2018-09-04 06:59:42 +08:00
|
|
|
*
|
|
|
|
* We will enter general_protection with kernel GSBASE,
|
|
|
|
* which is what the stub expects, given that the faulting
|
|
|
|
* RIP will be the IRET instruction.
|
2017-12-04 22:07:22 +08:00
|
|
|
*/
|
2020-02-26 06:16:25 +08:00
|
|
|
regs->ip = (unsigned long)asm_exc_general_protection;
|
2017-12-04 22:07:22 +08:00
|
|
|
regs->sp = (unsigned long)&gpregs->orig_ax;
|
2014-11-20 09:41:09 +08:00
|
|
|
|
2014-11-23 10:00:31 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2020-02-19 16:46:43 +08:00
|
|
|
nmi_enter();
|
2012-03-10 08:07:10 +08:00
|
|
|
notify_die(DIE_TRAP, str, regs, error_code, X86_TRAP_DF, SIGSEGV);
|
2008-10-04 04:00:39 +08:00
|
|
|
|
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 17:25:55 +08:00
|
|
|
tsk->thread.trap_nr = X86_TRAP_DF;
|
2008-10-04 04:00:39 +08:00
|
|
|
|
2016-08-11 17:35:23 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
|
|
|
/*
|
|
|
|
* If we overflow the stack into a guard page, the CPU will fail
|
|
|
|
* to deliver #PF and will send #DF instead. Similarly, if we
|
|
|
|
* take any non-IST exception while too close to the bottom of
|
|
|
|
* the stack, the processor will get a page fault while
|
|
|
|
* delivering the exception and will generate a double fault.
|
|
|
|
*
|
|
|
|
* According to the SDM (footnote in 6.15 under "Interrupt 14 -
|
|
|
|
* Page-Fault Exception (#PF):
|
|
|
|
*
|
|
|
|
* Processors update CR2 whenever a page fault is detected. If a
|
|
|
|
* second page fault occurs while an earlier page fault is being
|
2017-12-04 22:07:22 +08:00
|
|
|
* delivered, the faulting linear address of the second fault will
|
2016-08-11 17:35:23 +08:00
|
|
|
* overwrite the contents of CR2 (replacing the previous
|
|
|
|
* address). These updates to CR2 occur even if the page fault
|
|
|
|
* results in a double fault or occurs during the delivery of a
|
|
|
|
* double fault.
|
|
|
|
*
|
|
|
|
* The logic below has a small possibility of incorrectly diagnosing
|
|
|
|
* some errors as stack overflows. For example, if the IDT or GDT
|
|
|
|
* gets corrupted such that #GP delivery fails due to a bad descriptor
|
|
|
|
* causing #GP and we hit this condition while CR2 coincidentally
|
|
|
|
* points to the stack guard page, we'll think we overflowed the
|
|
|
|
* stack. Given that we're going to panic one way or another
|
|
|
|
* if this happens, this isn't necessarily worth fixing.
|
|
|
|
*
|
|
|
|
* If necessary, we could improve the test by only diagnosing
|
|
|
|
* a stack overflow if the saved RSP points within 47 bytes of
|
|
|
|
* the bottom of the stack: if RSP == tsk_stack + 48 and we
|
|
|
|
* take an exception, the stack is already aligned and there
|
|
|
|
* will be enough room SS, RSP, RFLAGS, CS, RIP, and a
|
|
|
|
* possible error code, so a stack overflow would *not* double
|
|
|
|
* fault. With any less space left, exception delivery could
|
|
|
|
* fail, and, as a practical matter, we've overflowed the
|
|
|
|
* stack even if the actual trigger for the double fault was
|
|
|
|
* something else.
|
|
|
|
*/
|
|
|
|
if ((unsigned long)task_stack_page(tsk) - 1 - cr2 < PAGE_SIZE)
|
|
|
|
handle_stack_overflow("kernel stack overflow (double-fault)", regs, cr2);
|
|
|
|
#endif
|
|
|
|
|
2019-11-21 14:12:38 +08:00
|
|
|
pr_emerg("PANIC: double fault, error_code: 0x%lx\n", error_code);
|
2019-11-26 14:37:44 +08:00
|
|
|
die("double fault", regs, error_code);
|
2019-11-21 14:12:38 +08:00
|
|
|
panic("Machine halted.");
|
2008-10-04 04:00:39 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:17 +08:00
|
|
|
DEFINE_IDTENTRY(exc_bounds)
|
x86, mpx: On-demand kernel allocation of bounds tables
This is really the meat of the MPX patch set. If there is one patch to
review in the entire series, this is the one. There is a new ABI here
and this kernel code also interacts with userspace memory in a
relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the
management of bounds tables in kernel, including on-demand kernel
allocation (See the patch "on-demand kernel allocation of bounds tables")
and cleanup (See the patch "cleanup unused bound tables"). Applications
do not strictly need the kernel to manage bounds tables and we expect
some applications to use MPX without taking advantage of this kernel
support. This means the kernel can not simply infer whether an application
needs bounds table management from the MPX registers. The prctl() is an
explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to
require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't
want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel
won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds
directory out of a userspace register (bndcfgu) and then cache it into
a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT
will set "bd_addr" to an invalid address. Using this scheme, we can
use "bd_addr" to determine whether the management of bounds tables in
kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves,
which can be expensive. Caching "bd_addr" like this also helps reduce
the cost of those xsaves when doing table cleanup at munmap() time.
Unfortunately, we can not apply this optimization to #BR fault time
because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information.
If MPX-enabled code needs more than these 4 registers, it needs to
spill them somewhere. It has two special instructions for this
which allow the bounds to be moved between the bounds registers
and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by
the MPX hardware during both bounds violations or when the tables
are not present. This patch handles those #BR exceptions for
not-present tables by carving the space out of the normal processes
address space (essentially calling the new mmap() interface indroduced
earlier in this patch set.) and then pointing the bounds-directory
over to it.
The tables *need* to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register pointing to
memory is dereferenced. Any direct kernel involvement (like a syscall)
to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel.
However, MPX does not strictly *require* anything in the kernel.
It can theoretically be done completely from userspace. Here are
a few ways this *could* be done. I don't think any of them are
practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds
directory. If we were to preallocate them for the 128TB of
user virtual address space, we would need to reserve 512TB+2GB,
which is larger than the entire virtual address space today.
This means they can not be reserved ahead of time. Also, a
single process's pre-popualated bounds directory consumes 2GB
of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually
need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small,
constrained applications. But, it isn't practical at a larger
scale since a given app has no way of controlling how all the
parts of the app might allocate memory (think libraries). The
kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still
requires locking or nasty tricks to keep track of the
allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 23:18:29 +08:00
|
|
|
{
|
2020-02-26 06:16:17 +08:00
|
|
|
if (notify_die(DIE_TRAP, "bounds", regs, 0,
|
x86, mpx: On-demand kernel allocation of bounds tables
This is really the meat of the MPX patch set. If there is one patch to
review in the entire series, this is the one. There is a new ABI here
and this kernel code also interacts with userspace memory in a
relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the
management of bounds tables in kernel, including on-demand kernel
allocation (See the patch "on-demand kernel allocation of bounds tables")
and cleanup (See the patch "cleanup unused bound tables"). Applications
do not strictly need the kernel to manage bounds tables and we expect
some applications to use MPX without taking advantage of this kernel
support. This means the kernel can not simply infer whether an application
needs bounds table management from the MPX registers. The prctl() is an
explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to
require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't
want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel
won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds
directory out of a userspace register (bndcfgu) and then cache it into
a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT
will set "bd_addr" to an invalid address. Using this scheme, we can
use "bd_addr" to determine whether the management of bounds tables in
kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves,
which can be expensive. Caching "bd_addr" like this also helps reduce
the cost of those xsaves when doing table cleanup at munmap() time.
Unfortunately, we can not apply this optimization to #BR fault time
because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information.
If MPX-enabled code needs more than these 4 registers, it needs to
spill them somewhere. It has two special instructions for this
which allow the bounds to be moved between the bounds registers
and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by
the MPX hardware during both bounds violations or when the tables
are not present. This patch handles those #BR exceptions for
not-present tables by carving the space out of the normal processes
address space (essentially calling the new mmap() interface indroduced
earlier in this patch set.) and then pointing the bounds-directory
over to it.
The tables *need* to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register pointing to
memory is dereferenced. Any direct kernel involvement (like a syscall)
to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel.
However, MPX does not strictly *require* anything in the kernel.
It can theoretically be done completely from userspace. Here are
a few ways this *could* be done. I don't think any of them are
practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds
directory. If we were to preallocate them for the 128TB of
user virtual address space, we would need to reserve 512TB+2GB,
which is larger than the entire virtual address space today.
This means they can not be reserved ahead of time. Also, a
single process's pre-popualated bounds directory consumes 2GB
of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually
need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small,
constrained applications. But, it isn't practical at a larger
scale since a given app has no way of controlling how all the
parts of the app might allocate memory (think libraries). The
kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still
requires locking or nasty tricks to keep track of the
allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 23:18:29 +08:00
|
|
|
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
|
2015-07-04 03:44:32 +08:00
|
|
|
return;
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
x86, mpx: On-demand kernel allocation of bounds tables
This is really the meat of the MPX patch set. If there is one patch to
review in the entire series, this is the one. There is a new ABI here
and this kernel code also interacts with userspace memory in a
relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the
management of bounds tables in kernel, including on-demand kernel
allocation (See the patch "on-demand kernel allocation of bounds tables")
and cleanup (See the patch "cleanup unused bound tables"). Applications
do not strictly need the kernel to manage bounds tables and we expect
some applications to use MPX without taking advantage of this kernel
support. This means the kernel can not simply infer whether an application
needs bounds table management from the MPX registers. The prctl() is an
explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to
require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't
want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel
won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds
directory out of a userspace register (bndcfgu) and then cache it into
a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT
will set "bd_addr" to an invalid address. Using this scheme, we can
use "bd_addr" to determine whether the management of bounds tables in
kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves,
which can be expensive. Caching "bd_addr" like this also helps reduce
the cost of those xsaves when doing table cleanup at munmap() time.
Unfortunately, we can not apply this optimization to #BR fault time
because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information.
If MPX-enabled code needs more than these 4 registers, it needs to
spill them somewhere. It has two special instructions for this
which allow the bounds to be moved between the bounds registers
and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by
the MPX hardware during both bounds violations or when the tables
are not present. This patch handles those #BR exceptions for
not-present tables by carving the space out of the normal processes
address space (essentially calling the new mmap() interface indroduced
earlier in this patch set.) and then pointing the bounds-directory
over to it.
The tables *need* to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register pointing to
memory is dereferenced. Any direct kernel involvement (like a syscall)
to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel.
However, MPX does not strictly *require* anything in the kernel.
It can theoretically be done completely from userspace. Here are
a few ways this *could* be done. I don't think any of them are
practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds
directory. If we were to preallocate them for the 128TB of
user virtual address space, we would need to reserve 512TB+2GB,
which is larger than the entire virtual address space today.
This means they can not be reserved ahead of time. Also, a
single process's pre-popualated bounds directory consumes 2GB
of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually
need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small,
constrained applications. But, it isn't practical at a larger
scale since a given app has no way of controlling how all the
parts of the app might allocate memory (think libraries). The
kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still
requires locking or nasty tricks to keep track of the
allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 23:18:29 +08:00
|
|
|
|
2015-03-19 09:33:33 +08:00
|
|
|
if (!user_mode(regs))
|
2020-02-26 06:16:17 +08:00
|
|
|
die("bounds", regs, 0);
|
x86, mpx: On-demand kernel allocation of bounds tables
This is really the meat of the MPX patch set. If there is one patch to
review in the entire series, this is the one. There is a new ABI here
and this kernel code also interacts with userspace memory in a
relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the
management of bounds tables in kernel, including on-demand kernel
allocation (See the patch "on-demand kernel allocation of bounds tables")
and cleanup (See the patch "cleanup unused bound tables"). Applications
do not strictly need the kernel to manage bounds tables and we expect
some applications to use MPX without taking advantage of this kernel
support. This means the kernel can not simply infer whether an application
needs bounds table management from the MPX registers. The prctl() is an
explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to
require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't
want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel
won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds
directory out of a userspace register (bndcfgu) and then cache it into
a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT
will set "bd_addr" to an invalid address. Using this scheme, we can
use "bd_addr" to determine whether the management of bounds tables in
kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves,
which can be expensive. Caching "bd_addr" like this also helps reduce
the cost of those xsaves when doing table cleanup at munmap() time.
Unfortunately, we can not apply this optimization to #BR fault time
because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information.
If MPX-enabled code needs more than these 4 registers, it needs to
spill them somewhere. It has two special instructions for this
which allow the bounds to be moved between the bounds registers
and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by
the MPX hardware during both bounds violations or when the tables
are not present. This patch handles those #BR exceptions for
not-present tables by carving the space out of the normal processes
address space (essentially calling the new mmap() interface indroduced
earlier in this patch set.) and then pointing the bounds-directory
over to it.
The tables *need* to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register pointing to
memory is dereferenced. Any direct kernel involvement (like a syscall)
to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel.
However, MPX does not strictly *require* anything in the kernel.
It can theoretically be done completely from userspace. Here are
a few ways this *could* be done. I don't think any of them are
practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds
directory. If we were to preallocate them for the 128TB of
user virtual address space, we would need to reserve 512TB+2GB,
which is larger than the entire virtual address space today.
This means they can not be reserved ahead of time. Also, a
single process's pre-popualated bounds directory consumes 2GB
of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually
need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small,
constrained applications. But, it isn't practical at a larger
scale since a given app has no way of controlling how all the
parts of the app might allocate memory (think libraries). The
kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still
requires locking or nasty tricks to keep track of the
allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 23:18:29 +08:00
|
|
|
|
2020-02-26 06:16:17 +08:00
|
|
|
do_trap(X86_TRAP_BR, SIGSEGV, "bounds", regs, 0, 0, NULL);
|
2019-10-23 20:27:10 +08:00
|
|
|
|
|
|
|
cond_local_irq_disable(regs);
|
x86, mpx: On-demand kernel allocation of bounds tables
This is really the meat of the MPX patch set. If there is one patch to
review in the entire series, this is the one. There is a new ABI here
and this kernel code also interacts with userspace memory in a
relatively unusual manner. (small FAQ below).
Long Description:
This patch adds two prctl() commands to provide enable or disable the
management of bounds tables in kernel, including on-demand kernel
allocation (See the patch "on-demand kernel allocation of bounds tables")
and cleanup (See the patch "cleanup unused bound tables"). Applications
do not strictly need the kernel to manage bounds tables and we expect
some applications to use MPX without taking advantage of this kernel
support. This means the kernel can not simply infer whether an application
needs bounds table management from the MPX registers. The prctl() is an
explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to
require kernel's help in managing bounds tables.
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't
want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, the kernel
won't allocate and free bounds tables even if the CPU supports MPX.
PR_MPX_ENABLE_MANAGEMENT will fetch the base address of the bounds
directory out of a userspace register (bndcfgu) and then cache it into
a new field (->bd_addr) in the 'mm_struct'. PR_MPX_DISABLE_MANAGEMENT
will set "bd_addr" to an invalid address. Using this scheme, we can
use "bd_addr" to determine whether the management of bounds tables in
kernel is enabled.
Also, the only way to access that bndcfgu register is via an xsaves,
which can be expensive. Caching "bd_addr" like this also helps reduce
the cost of those xsaves when doing table cleanup at munmap() time.
Unfortunately, we can not apply this optimization to #BR fault time
because we need an xsave to get the value of BNDSTATUS.
==== Why does the hardware even have these Bounds Tables? ====
MPX only has 4 hardware registers for storing bounds information.
If MPX-enabled code needs more than these 4 registers, it needs to
spill them somewhere. It has two special instructions for this
which allow the bounds to be moved between the bounds registers
and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by
the MPX hardware during both bounds violations or when the tables
are not present. This patch handles those #BR exceptions for
not-present tables by carving the space out of the normal processes
address space (essentially calling the new mmap() interface indroduced
earlier in this patch set.) and then pointing the bounds-directory
over to it.
The tables *need* to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register pointing to
memory is dereferenced. Any direct kernel involvement (like a syscall)
to access the tables would obviously destroy performance.
==== Why not do this in userspace? ====
This patch is obviously doing this allocation in the kernel.
However, MPX does not strictly *require* anything in the kernel.
It can theoretically be done completely from userspace. Here are
a few ways this *could* be done. I don't think any of them are
practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds
directory. If we were to preallocate them for the 128TB of
user virtual address space, we would need to reserve 512TB+2GB,
which is larger than the entire virtual address space today.
This means they can not be reserved ahead of time. Also, a
single process's pre-popualated bounds directory consumes 2GB
of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually
need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small,
constrained applications. But, it isn't practical at a larger
scale since a given app has no way of controlling how all the
parts of the app might allocate memory (think libraries). The
kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still
requires locking or nasty tricks to keep track of the
allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Based-on-patch-by: Qiaowei Ren <qiaowei.ren@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-mm@kvack.org
Cc: linux-mips@linux-mips.org
Cc: Dave Hansen <dave@sr71.net>
Link: http://lkml.kernel.org/r/20141114151829.AD4310DE@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-11-14 23:18:29 +08:00
|
|
|
}
|
|
|
|
|
x86/traps: Print address on #GP
A frequent cause of #GP exceptions are memory accesses to non-canonical
addresses. Unlike #PF, #GP doesn't report a fault address in CR2, so the
kernel doesn't currently print the fault address for a #GP.
Luckily, the necessary infrastructure for decoding x86 instructions and
computing the memory address being accessed is already present. Hook
it up to the #GP handler so that the address operand of the faulting
instruction can be figured out and printed.
Distinguish two cases:
a) (Part of) the memory range being accessed lies in the non-canonical
address range; in this case, it is likely that the decoded address
is actually the one that caused the #GP.
b) The entire memory range of the decoded operand lies in canonical
address space; the #GP may or may not be related in some way to the
computed address. Print it, but with hedging language in the message.
While it is already possible to compute the faulting address manually by
disassembling the opcode dump and evaluating the instruction against the
register dump, this should make it slightly easier to identify crashes
at a glance.
Note that the operand length which comes from the instruction decoder
and is used to determine whether the access straddles into non-canonical
address space, is currently somewhat unreliable; but it should be good
enough, considering that Linux on x86-64 never maps the page directly
before the start of the non-canonical range anyway, and therefore the
case where a memory range begins in that page and potentially straddles
into the non-canonical range should be fairly uncommon.
In the case the address is still computed wrongly, it only influences
whether the error message claims that the access is canonical.
[ bp: Remove ambiguous "we", massage, reflow comments and spacing. ]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: kasan-dev@googlegroups.com
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191218231150.12139-2-jannh@google.com
2019-12-19 07:11:48 +08:00
|
|
|
enum kernel_gp_hint {
|
|
|
|
GP_NO_HINT,
|
|
|
|
GP_NON_CANONICAL,
|
|
|
|
GP_CANONICAL
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When an uncaught #GP occurs, try to determine the memory address accessed by
|
|
|
|
* the instruction and return that address to the caller. Also, try to figure
|
|
|
|
* out whether any part of the access to that address was non-canonical.
|
|
|
|
*/
|
|
|
|
static enum kernel_gp_hint get_kernel_gp_address(struct pt_regs *regs,
|
|
|
|
unsigned long *addr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
x86/traps: Print address on #GP
A frequent cause of #GP exceptions are memory accesses to non-canonical
addresses. Unlike #PF, #GP doesn't report a fault address in CR2, so the
kernel doesn't currently print the fault address for a #GP.
Luckily, the necessary infrastructure for decoding x86 instructions and
computing the memory address being accessed is already present. Hook
it up to the #GP handler so that the address operand of the faulting
instruction can be figured out and printed.
Distinguish two cases:
a) (Part of) the memory range being accessed lies in the non-canonical
address range; in this case, it is likely that the decoded address
is actually the one that caused the #GP.
b) The entire memory range of the decoded operand lies in canonical
address space; the #GP may or may not be related in some way to the
computed address. Print it, but with hedging language in the message.
While it is already possible to compute the faulting address manually by
disassembling the opcode dump and evaluating the instruction against the
register dump, this should make it slightly easier to identify crashes
at a glance.
Note that the operand length which comes from the instruction decoder
and is used to determine whether the access straddles into non-canonical
address space, is currently somewhat unreliable; but it should be good
enough, considering that Linux on x86-64 never maps the page directly
before the start of the non-canonical range anyway, and therefore the
case where a memory range begins in that page and potentially straddles
into the non-canonical range should be fairly uncommon.
In the case the address is still computed wrongly, it only influences
whether the error message claims that the access is canonical.
[ bp: Remove ambiguous "we", massage, reflow comments and spacing. ]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: kasan-dev@googlegroups.com
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191218231150.12139-2-jannh@google.com
2019-12-19 07:11:48 +08:00
|
|
|
u8 insn_buf[MAX_INSN_SIZE];
|
|
|
|
struct insn insn;
|
|
|
|
|
|
|
|
if (probe_kernel_read(insn_buf, (void *)regs->ip, MAX_INSN_SIZE))
|
|
|
|
return GP_NO_HINT;
|
|
|
|
|
|
|
|
kernel_insn_init(&insn, insn_buf, MAX_INSN_SIZE);
|
|
|
|
insn_get_modrm(&insn);
|
|
|
|
insn_get_sib(&insn);
|
|
|
|
|
|
|
|
*addr = (unsigned long)insn_get_addr_ref(&insn, regs);
|
|
|
|
if (*addr == -1UL)
|
|
|
|
return GP_NO_HINT;
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
/*
|
|
|
|
* Check that:
|
|
|
|
* - the operand is not in the kernel half
|
|
|
|
* - the last byte of the operand is not in the user canonical half
|
|
|
|
*/
|
|
|
|
if (*addr < ~__VIRTUAL_MASK &&
|
|
|
|
*addr + insn.opnd_bytes - 1 > __VIRTUAL_MASK)
|
|
|
|
return GP_NON_CANONICAL;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return GP_CANONICAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define GPFSTR "general protection fault"
|
|
|
|
|
2020-02-26 06:16:25 +08:00
|
|
|
DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
x86/traps: Print address on #GP
A frequent cause of #GP exceptions are memory accesses to non-canonical
addresses. Unlike #PF, #GP doesn't report a fault address in CR2, so the
kernel doesn't currently print the fault address for a #GP.
Luckily, the necessary infrastructure for decoding x86 instructions and
computing the memory address being accessed is already present. Hook
it up to the #GP handler so that the address operand of the faulting
instruction can be figured out and printed.
Distinguish two cases:
a) (Part of) the memory range being accessed lies in the non-canonical
address range; in this case, it is likely that the decoded address
is actually the one that caused the #GP.
b) The entire memory range of the decoded operand lies in canonical
address space; the #GP may or may not be related in some way to the
computed address. Print it, but with hedging language in the message.
While it is already possible to compute the faulting address manually by
disassembling the opcode dump and evaluating the instruction against the
register dump, this should make it slightly easier to identify crashes
at a glance.
Note that the operand length which comes from the instruction decoder
and is used to determine whether the access straddles into non-canonical
address space, is currently somewhat unreliable; but it should be good
enough, considering that Linux on x86-64 never maps the page directly
before the start of the non-canonical range anyway, and therefore the
case where a memory range begins in that page and potentially straddles
into the non-canonical range should be fairly uncommon.
In the case the address is still computed wrongly, it only influences
whether the error message claims that the access is canonical.
[ bp: Remove ambiguous "we", massage, reflow comments and spacing. ]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: kasan-dev@googlegroups.com
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191218231150.12139-2-jannh@google.com
2019-12-19 07:11:48 +08:00
|
|
|
char desc[sizeof(GPFSTR) + 50 + 2*sizeof(unsigned long) + 1] = GPFSTR;
|
2020-01-01 00:15:35 +08:00
|
|
|
enum kernel_gp_hint hint = GP_NO_HINT;
|
2008-07-02 07:32:04 +08:00
|
|
|
struct task_struct *tsk;
|
2020-01-01 00:15:35 +08:00
|
|
|
unsigned long gp_addr;
|
|
|
|
int ret;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2008-09-10 03:56:07 +08:00
|
|
|
|
2017-11-06 10:27:55 +08:00
|
|
|
if (static_cpu_has(X86_FEATURE_UMIP)) {
|
|
|
|
if (user_mode(regs) && fixup_umip_exception(regs))
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2017-11-06 10:27:55 +08:00
|
|
|
}
|
|
|
|
|
2015-03-19 09:33:35 +08:00
|
|
|
if (v8086_mode(regs)) {
|
2012-09-25 03:05:52 +08:00
|
|
|
local_irq_enable();
|
|
|
|
handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
|
2019-10-23 20:27:10 +08:00
|
|
|
local_irq_disable();
|
2015-07-04 03:44:32 +08:00
|
|
|
return;
|
2012-09-25 03:05:52 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-07-02 07:32:04 +08:00
|
|
|
tsk = current;
|
2012-09-25 03:05:52 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
if (user_mode(regs)) {
|
2012-09-25 03:05:52 +08:00
|
|
|
tsk->thread.error_code = error_code;
|
|
|
|
tsk->thread.trap_nr = X86_TRAP_GP;
|
2018-08-29 04:14:16 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
show_signal(tsk, SIGSEGV, "", desc, regs, error_code);
|
|
|
|
force_sig(SIGSEGV);
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2012-09-25 03:05:52 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
if (fixup_exception(regs, X86_TRAP_GP, error_code, 0))
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
x86/traps: Print address on #GP
A frequent cause of #GP exceptions are memory accesses to non-canonical
addresses. Unlike #PF, #GP doesn't report a fault address in CR2, so the
kernel doesn't currently print the fault address for a #GP.
Luckily, the necessary infrastructure for decoding x86 instructions and
computing the memory address being accessed is already present. Hook
it up to the #GP handler so that the address operand of the faulting
instruction can be figured out and printed.
Distinguish two cases:
a) (Part of) the memory range being accessed lies in the non-canonical
address range; in this case, it is likely that the decoded address
is actually the one that caused the #GP.
b) The entire memory range of the decoded operand lies in canonical
address space; the #GP may or may not be related in some way to the
computed address. Print it, but with hedging language in the message.
While it is already possible to compute the faulting address manually by
disassembling the opcode dump and evaluating the instruction against the
register dump, this should make it slightly easier to identify crashes
at a glance.
Note that the operand length which comes from the instruction decoder
and is used to determine whether the access straddles into non-canonical
address space, is currently somewhat unreliable; but it should be good
enough, considering that Linux on x86-64 never maps the page directly
before the start of the non-canonical range anyway, and therefore the
case where a memory range begins in that page and potentially straddles
into the non-canonical range should be fairly uncommon.
In the case the address is still computed wrongly, it only influences
whether the error message claims that the access is canonical.
[ bp: Remove ambiguous "we", massage, reflow comments and spacing. ]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Tested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: kasan-dev@googlegroups.com
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191218231150.12139-2-jannh@google.com
2019-12-19 07:11:48 +08:00
|
|
|
|
2008-07-02 07:32:04 +08:00
|
|
|
tsk->thread.error_code = error_code;
|
2012-03-12 17:25:55 +08:00
|
|
|
tsk->thread.trap_nr = X86_TRAP_GP;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
/*
|
|
|
|
* To be potentially processing a kprobe fault and to trust the result
|
|
|
|
* from kprobe_running(), we have to be non-preemptible.
|
|
|
|
*/
|
|
|
|
if (!preemptible() &&
|
|
|
|
kprobe_running() &&
|
|
|
|
kprobe_fault_handler(regs, X86_TRAP_GP))
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2019-12-19 07:11:49 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
ret = notify_die(DIE_GPF, desc, regs, error_code, X86_TRAP_GP, SIGSEGV);
|
|
|
|
if (ret == NOTIFY_STOP)
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
if (error_code)
|
|
|
|
snprintf(desc, sizeof(desc), "segment-related " GPFSTR);
|
|
|
|
else
|
|
|
|
hint = get_kernel_gp_address(regs, &gp_addr);
|
|
|
|
|
|
|
|
if (hint != GP_NO_HINT)
|
|
|
|
snprintf(desc, sizeof(desc), GPFSTR ", %s 0x%lx",
|
|
|
|
(hint == GP_NON_CANONICAL) ? "probably for non-canonical address"
|
|
|
|
: "maybe for address",
|
|
|
|
gp_addr);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* KASAN is interested only in the non-canonical case, clear it
|
|
|
|
* otherwise.
|
|
|
|
*/
|
|
|
|
if (hint != GP_NON_CANONICAL)
|
|
|
|
gp_addr = 0;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2020-01-01 00:15:35 +08:00
|
|
|
die_addr(desc, regs, error_code, gp_addr);
|
2007-07-22 17:12:28 +08:00
|
|
|
|
2019-10-23 20:27:10 +08:00
|
|
|
exit:
|
|
|
|
cond_local_irq_disable(regs);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-04-17 16:18:14 +08:00
|
|
|
dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-07-23 16:09:28 +08:00
|
|
|
if (poke_int3_handler(regs))
|
|
|
|
return;
|
|
|
|
|
2015-07-24 06:37:48 +08:00
|
|
|
/*
|
2020-02-19 16:46:43 +08:00
|
|
|
* Unlike any other non-IST entry, we can be called from pretty much
|
|
|
|
* any location in the kernel through kprobes -- text_poke() will most
|
|
|
|
* likely be handled by poke_int3_handler() above. This means this
|
|
|
|
* handler is effectively NMI-like.
|
2015-07-24 06:37:48 +08:00
|
|
|
*/
|
2020-02-19 16:46:43 +08:00
|
|
|
if (!user_mode(regs))
|
|
|
|
nmi_enter();
|
2020-02-26 05:36:46 +08:00
|
|
|
|
2010-05-21 10:04:25 +08:00
|
|
|
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
|
2012-03-10 08:07:10 +08:00
|
|
|
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2010-05-21 10:04:25 +08:00
|
|
|
#endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
|
2011-10-25 22:21:59 +08:00
|
|
|
|
kprobes/x86: Call exception handlers directly from do_int3/do_debug
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler() and kprobe_debug_handler()(which was
formerly called post_kprobe_handler()) directly from
do_int3 and do_debug.
Currently kprobes uses notify_die() to hook the int3/debug
exceptoins. Since there is a locking code in notify_die,
the lockdep code can be invoked. And because the lockdep
involves printk() related things, theoretically, we need to
prohibit probing on such code, which means much longer blacklist
we'll have. Instead, hooking the int3/debug for kprobes before
notify_die() can avoid this problem.
Anyway, most of the int3 handlers in the kernel are already
called from do_int3 directly, e.g. ftrace_int3_handler,
poke_int3_handler, kgdb_ll_trap. Actually only
kprobe_exceptions_notify is on the notifier_call_chain.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Lebon <jlebon@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/20140417081733.26341.24423.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-04-17 16:17:33 +08:00
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_int3_handler(regs))
|
2014-06-14 14:47:12 +08:00
|
|
|
goto exit;
|
kprobes/x86: Call exception handlers directly from do_int3/do_debug
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler() and kprobe_debug_handler()(which was
formerly called post_kprobe_handler()) directly from
do_int3 and do_debug.
Currently kprobes uses notify_die() to hook the int3/debug
exceptoins. Since there is a locking code in notify_die,
the lockdep code can be invoked. And because the lockdep
involves printk() related things, theoretically, we need to
prohibit probing on such code, which means much longer blacklist
we'll have. Instead, hooking the int3/debug for kprobes before
notify_die() can avoid this problem.
Anyway, most of the int3 handlers in the kernel are already
called from do_int3 directly, e.g. ftrace_int3_handler,
poke_int3_handler, kgdb_ll_trap. Actually only
kprobe_exceptions_notify is on the notifier_call_chain.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Lebon <jlebon@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/20140417081733.26341.24423.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-04-17 16:17:33 +08:00
|
|
|
#endif
|
|
|
|
|
2012-03-10 08:07:10 +08:00
|
|
|
if (notify_die(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2008-02-26 18:15:50 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2018-04-17 03:29:39 +08:00
|
|
|
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, 0, NULL);
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2015-07-24 06:37:48 +08:00
|
|
|
|
2012-07-12 02:26:35 +08:00
|
|
|
exit:
|
2020-02-19 16:46:43 +08:00
|
|
|
if (!user_mode(regs))
|
|
|
|
nmi_exit();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_int3);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_64
|
2008-12-26 16:20:22 +08:00
|
|
|
/*
|
2017-12-04 22:07:23 +08:00
|
|
|
* Help handler running on a per-cpu (IST or entry trampoline) stack
|
|
|
|
* to switch to the normal thread stack if the interrupted code was in
|
|
|
|
* user mode. The actual stack switch is done in entry_64.S
|
2008-12-26 16:20:22 +08:00
|
|
|
*/
|
2020-03-26 06:47:51 +08:00
|
|
|
asmlinkage __visible noinstr struct pt_regs *sync_regs(struct pt_regs *eregs)
|
2008-10-04 04:00:39 +08:00
|
|
|
{
|
2017-12-04 22:07:23 +08:00
|
|
|
struct pt_regs *regs = (struct pt_regs *)this_cpu_read(cpu_current_top_of_stack) - 1;
|
|
|
|
if (regs != eregs)
|
|
|
|
*regs = *eregs;
|
2008-10-04 04:00:39 +08:00
|
|
|
return regs;
|
|
|
|
}
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
|
|
|
|
struct bad_iret_stack {
|
|
|
|
void *error_entry_ret;
|
|
|
|
struct pt_regs regs;
|
|
|
|
};
|
|
|
|
|
2020-03-26 02:53:38 +08:00
|
|
|
asmlinkage __visible noinstr
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
struct bad_iret_stack *fixup_bad_iret(struct bad_iret_stack *s)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This is called from entry_64.S early in handling a fault
|
|
|
|
* caused by a bad iret to user mode. To handle the fault
|
2017-12-04 22:07:23 +08:00
|
|
|
* correctly, we want to move our stack frame to where it would
|
|
|
|
* be had we entered directly on the entry stack (rather than
|
|
|
|
* just below the IRET frame) and we want to pretend that the
|
|
|
|
* exception came from the IRET target.
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
*/
|
2020-03-26 02:53:38 +08:00
|
|
|
struct bad_iret_stack tmp, *new_stack =
|
|
|
|
(struct bad_iret_stack *)__this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
|
2020-03-26 02:53:38 +08:00
|
|
|
/* Copy the IRET target to the temporary storage. */
|
|
|
|
memcpy(&tmp.regs.ip, (void *)s->regs.sp, 5*8);
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
|
|
|
|
/* Copy the remainder of the stack from the current stack. */
|
2020-03-26 02:53:38 +08:00
|
|
|
memcpy(&tmp, s, offsetof(struct bad_iret_stack, regs.ip));
|
|
|
|
|
|
|
|
/* Update the entry stack */
|
|
|
|
memcpy(new_stack, &tmp, sizeof(tmp));
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
|
2015-03-19 09:33:33 +08:00
|
|
|
BUG_ON(!user_mode(&new_stack->regs));
|
x86_64, traps: Rework bad_iret
It's possible for iretq to userspace to fail. This can happen because
of a bad CS, SS, or RIP.
Historically, we've handled it by fixing up an exception from iretq to
land at bad_iret, which pretends that the failed iret frame was really
the hardware part of #GP(0) from userspace. To make this work, there's
an extra fixup to fudge the gs base into a usable state.
This is suboptimal because it loses the original exception. It's also
buggy because there's no guarantee that we were on the kernel stack to
begin with. For example, if the failing iret happened on return from an
NMI, then we'll end up executing general_protection on the NMI stack.
This is bad for several reasons, the most immediate of which is that
general_protection, as a non-paranoid idtentry, will try to deliver
signals and/or schedule from the wrong stack.
This patch throws out bad_iret entirely. As a replacement, it augments
the existing swapgs fudge into a full-blown iret fixup, mostly written
in C. It's should be clearer and more correct.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-11-23 10:00:33 +08:00
|
|
|
return new_stack;
|
|
|
|
}
|
2008-10-04 04:00:39 +08:00
|
|
|
#endif
|
|
|
|
|
2016-03-10 11:00:30 +08:00
|
|
|
static bool is_sysenter_singlestep(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We don't try for precision here. If we're anywhere in the region of
|
|
|
|
* code that can be single-stepped in the SYSENTER entry path, then
|
|
|
|
* assume that this is a useless single-step trap due to SYSENTER
|
|
|
|
* being invoked with TF set. (We don't know in advance exactly
|
|
|
|
* which instructions will be hit because BTF could plausibly
|
|
|
|
* be set.)
|
|
|
|
*/
|
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
return (regs->ip - (unsigned long)__begin_SYSENTER_singlestep_region) <
|
|
|
|
(unsigned long)__end_SYSENTER_singlestep_region -
|
|
|
|
(unsigned long)__begin_SYSENTER_singlestep_region;
|
|
|
|
#elif defined(CONFIG_IA32_EMULATION)
|
|
|
|
return (regs->ip - (unsigned long)entry_SYSENTER_compat) <
|
|
|
|
(unsigned long)__end_entry_SYSENTER_compat -
|
|
|
|
(unsigned long)entry_SYSENTER_compat;
|
|
|
|
#else
|
|
|
|
return false;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Our handling of the processor debug registers is non-trivial.
|
|
|
|
* We do not clear them on entry and exit from the kernel. Therefore
|
|
|
|
* it is possible to get a watchpoint trap here from inside the kernel.
|
|
|
|
* However, the code in ./ptrace.c has ensured that the user can
|
|
|
|
* only set watchpoints on userspace addresses. Therefore the in-kernel
|
|
|
|
* watchpoint trap can only occur in code which is reading/writing
|
|
|
|
* from user space. Such code must not hold kernel locks (since it
|
|
|
|
* can equally take a page fault), therefore it is safe to call
|
|
|
|
* force_sig_info even though that claims and releases locks.
|
2008-02-26 18:15:50 +08:00
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* Code in ./signal.c ensures that the debug control register
|
|
|
|
* is restored before we deliver any signal, and therefore that
|
|
|
|
* user code runs with the correct debug control register even though
|
|
|
|
* we clear it here.
|
|
|
|
*
|
|
|
|
* Being careful here means that we don't have to be as careful in a
|
|
|
|
* lot of more complicated places (task switching can be a bit lazy
|
|
|
|
* about restoring all the debug state, and ptrace doesn't have to
|
|
|
|
* find every occurrence of the TF bit that could be saved away even
|
|
|
|
* by user code)
|
2008-10-04 05:17:11 +08:00
|
|
|
*
|
|
|
|
* May run on IST stack.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2014-04-17 16:18:14 +08:00
|
|
|
dotraplinkage void do_debug(struct pt_regs *regs, long error_code)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct task_struct *tsk = current;
|
2010-06-30 21:09:06 +08:00
|
|
|
int user_icebp = 0;
|
2009-06-02 02:14:08 +08:00
|
|
|
unsigned long dr6;
|
2008-09-23 17:53:52 +08:00
|
|
|
int si_code;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-02-19 16:46:43 +08:00
|
|
|
nmi_enter();
|
2014-06-14 14:47:12 +08:00
|
|
|
|
2009-06-02 02:14:08 +08:00
|
|
|
get_debugreg(dr6, 6);
|
2016-03-10 11:00:29 +08:00
|
|
|
/*
|
|
|
|
* The Intel SDM says:
|
|
|
|
*
|
|
|
|
* Certain debug exceptions may clear bits 0-3. The remaining
|
|
|
|
* contents of the DR6 register are never cleared by the
|
|
|
|
* processor. To avoid confusion in identifying debug
|
|
|
|
* exceptions, debug handlers should clear the register before
|
|
|
|
* returning to the interrupted task.
|
|
|
|
*
|
|
|
|
* Keep it simple: clear DR6 immediately.
|
|
|
|
*/
|
|
|
|
set_debugreg(0, 6);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-01-28 19:14:01 +08:00
|
|
|
/* Filter out all the reserved bits which are preset to 1 */
|
|
|
|
dr6 &= ~DR6_RESERVED;
|
|
|
|
|
2016-03-10 11:00:28 +08:00
|
|
|
/*
|
|
|
|
* The SDM says "The processor clears the BTF flag when it
|
|
|
|
* generates a debug exception." Clear TIF_BLOCKSTEP to keep
|
|
|
|
* TIF_BLOCKSTEP in sync with the hardware BTF flag.
|
|
|
|
*/
|
|
|
|
clear_tsk_thread_flag(tsk, TIF_BLOCKSTEP);
|
|
|
|
|
2016-03-10 11:00:30 +08:00
|
|
|
if (unlikely(!user_mode(regs) && (dr6 & DR_STEP) &&
|
|
|
|
is_sysenter_singlestep(regs))) {
|
|
|
|
dr6 &= ~DR_STEP;
|
|
|
|
if (!dr6)
|
|
|
|
goto exit;
|
|
|
|
/*
|
|
|
|
* else we might have gotten a single-step trap and hit a
|
|
|
|
* watchpoint at the same time, in which case we should fall
|
|
|
|
* through and handle the watchpoint.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
2010-06-30 21:09:06 +08:00
|
|
|
/*
|
|
|
|
* If dr6 has no reason to give us about the origin of this trap,
|
|
|
|
* then it's very likely the result of an icebp/int01 trap.
|
|
|
|
* User wants a sigtrap for that.
|
|
|
|
*/
|
2015-03-19 09:33:33 +08:00
|
|
|
if (!dr6 && user_mode(regs))
|
2010-06-30 21:09:06 +08:00
|
|
|
user_icebp = 1;
|
|
|
|
|
2009-06-02 02:14:08 +08:00
|
|
|
/* Store the virtualized DR6 value */
|
|
|
|
tsk->thread.debugreg6 = dr6;
|
|
|
|
|
kprobes/x86: Call exception handlers directly from do_int3/do_debug
To avoid a kernel crash by probing on lockdep code, call
kprobe_int3_handler() and kprobe_debug_handler()(which was
formerly called post_kprobe_handler()) directly from
do_int3 and do_debug.
Currently kprobes uses notify_die() to hook the int3/debug
exceptoins. Since there is a locking code in notify_die,
the lockdep code can be invoked. And because the lockdep
involves printk() related things, theoretically, we need to
prohibit probing on such code, which means much longer blacklist
we'll have. Instead, hooking the int3/debug for kprobes before
notify_die() can avoid this problem.
Anyway, most of the int3 handlers in the kernel are already
called from do_int3 directly, e.g. ftrace_int3_handler,
poke_int3_handler, kgdb_ll_trap. Actually only
kprobe_exceptions_notify is on the notifier_call_chain.
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Jonathan Lebon <jlebon@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Link: http://lkml.kernel.org/r/20140417081733.26341.24423.stgit@ltc230.yrl.intra.hitachi.co.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-04-17 16:17:33 +08:00
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_debug_handler(regs))
|
|
|
|
goto exit;
|
|
|
|
#endif
|
|
|
|
|
2013-06-16 12:42:47 +08:00
|
|
|
if (notify_die(DIE_DEBUG, "debug", regs, (long)&dr6, error_code,
|
2009-06-02 02:17:06 +08:00
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2008-10-01 00:41:37 +08:00
|
|
|
|
2011-12-17 00:43:02 +08:00
|
|
|
/*
|
|
|
|
* Let others (NMI) know that the debug stack is in use
|
|
|
|
* as we may switch to the interrupt stack.
|
|
|
|
*/
|
|
|
|
debug_stack_usage_inc();
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* It's safe to allow irq's after DR6 has been saved */
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-03-19 09:33:35 +08:00
|
|
|
if (v8086_mode(regs)) {
|
2012-03-10 08:07:10 +08:00
|
|
|
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
|
|
|
|
X86_TRAP_DB);
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2011-12-17 00:43:02 +08:00
|
|
|
debug_stack_usage_dec();
|
2012-07-12 02:26:35 +08:00
|
|
|
goto exit;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-03-10 11:00:30 +08:00
|
|
|
if (WARN_ON_ONCE((dr6 & DR_STEP) && !user_mode(regs))) {
|
|
|
|
/*
|
|
|
|
* Historical junk that used to handle SYSENTER single-stepping.
|
|
|
|
* This should be unreachable now. If we survive for a while
|
|
|
|
* without anyone hitting this warning, we'll turn this into
|
|
|
|
* an oops.
|
|
|
|
*/
|
2009-06-02 02:14:08 +08:00
|
|
|
tsk->thread.debugreg6 &= ~DR_STEP;
|
|
|
|
set_tsk_thread_flag(tsk, TIF_SINGLESTEP);
|
|
|
|
regs->flags &= ~X86_EFLAGS_TF;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2009-06-02 02:14:08 +08:00
|
|
|
si_code = get_si_code(tsk->thread.debugreg6);
|
2010-06-30 21:09:06 +08:00
|
|
|
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
|
2019-02-06 08:25:11 +08:00
|
|
|
send_sigtrap(regs, error_code, si_code);
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_disable(regs);
|
2011-12-17 00:43:02 +08:00
|
|
|
debug_stack_usage_dec();
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-07-12 02:26:35 +08:00
|
|
|
exit:
|
2020-02-19 16:46:43 +08:00
|
|
|
nmi_exit();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-17 16:18:14 +08:00
|
|
|
NOKPROBE_SYMBOL(do_debug);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that we play around with the 'TS' bit in an attempt to get
|
|
|
|
* the correct behaviour even in the presence of the asynchronous
|
|
|
|
* IRQ13 behaviour
|
|
|
|
*/
|
2020-02-26 06:16:29 +08:00
|
|
|
static void math_error(struct pt_regs *regs, int trapnr)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2010-03-21 21:00:45 +08:00
|
|
|
struct task_struct *task = current;
|
2015-04-30 15:29:38 +08:00
|
|
|
struct fpu *fpu = &task->thread.fpu;
|
2018-09-18 07:16:39 +08:00
|
|
|
int si_code;
|
2012-03-10 08:07:10 +08:00
|
|
|
char *str = (trapnr == X86_TRAP_MF) ? "fpu exception" :
|
|
|
|
"simd exception";
|
2010-03-21 21:00:45 +08:00
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2010-03-21 21:00:45 +08:00
|
|
|
|
2015-04-30 15:29:38 +08:00
|
|
|
if (!user_mode(regs)) {
|
2020-02-26 06:16:29 +08:00
|
|
|
if (fixup_exception(regs, trapnr, 0, 0))
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2018-06-15 03:36:07 +08:00
|
|
|
|
2020-02-26 06:16:29 +08:00
|
|
|
task->thread.error_code = 0;
|
2018-06-15 03:36:07 +08:00
|
|
|
task->thread.trap_nr = trapnr;
|
|
|
|
|
2020-02-26 06:16:29 +08:00
|
|
|
if (notify_die(DIE_TRAP, str, regs, 0, trapnr,
|
|
|
|
SIGFPE) != NOTIFY_STOP)
|
|
|
|
die(str, regs, 0);
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2010-03-21 21:00:45 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Save the info for the exception handler and clear the error.
|
|
|
|
*/
|
2015-04-30 15:29:38 +08:00
|
|
|
fpu__save(fpu);
|
|
|
|
|
|
|
|
task->thread.trap_nr = trapnr;
|
2020-02-26 06:16:29 +08:00
|
|
|
task->thread.error_code = 0;
|
2008-12-23 09:56:05 +08:00
|
|
|
|
2018-09-18 07:16:39 +08:00
|
|
|
si_code = fpu__exception_code(fpu, trapnr);
|
2015-04-30 15:29:38 +08:00
|
|
|
/* Retry when we get spurious exceptions: */
|
2018-09-18 07:16:39 +08:00
|
|
|
if (!si_code)
|
2019-10-23 20:27:10 +08:00
|
|
|
goto exit;
|
2015-04-30 15:29:38 +08:00
|
|
|
|
2018-09-18 07:16:39 +08:00
|
|
|
force_sig_fault(SIGFPE, si_code,
|
2019-05-24 00:04:24 +08:00
|
|
|
(void __user *)uprobe_get_trap_addr(regs));
|
2019-10-23 20:27:10 +08:00
|
|
|
exit:
|
|
|
|
cond_local_irq_disable(regs);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:27 +08:00
|
|
|
DEFINE_IDTENTRY(exc_coprocessor_error)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2020-02-26 06:16:29 +08:00
|
|
|
math_error(regs, X86_TRAP_MF);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:29 +08:00
|
|
|
DEFINE_IDTENTRY(exc_simd_coprocessor_error)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2020-02-26 06:16:29 +08:00
|
|
|
if (IS_ENABLED(CONFIG_X86_INVD_BUG)) {
|
|
|
|
/* AMD 486 bug: INVD in CPL 0 raises #XF instead of #GP */
|
|
|
|
if (!static_cpu_has(X86_FEATURE_XMM)) {
|
|
|
|
__exc_general_protection(regs, 0);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
math_error(regs, X86_TRAP_XF);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:26 +08:00
|
|
|
DEFINE_IDTENTRY(exc_spurious_interrupt_bug)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2020-02-26 05:36:41 +08:00
|
|
|
/*
|
|
|
|
* This addresses a Pentium Pro Erratum:
|
|
|
|
*
|
|
|
|
* PROBLEM: If the APIC subsystem is configured in mixed mode with
|
|
|
|
* Virtual Wire mode implemented through the local APIC, an
|
|
|
|
* interrupt vector of 0Fh (Intel reserved encoding) may be
|
|
|
|
* generated by the local APIC (Int 15). This vector may be
|
|
|
|
* generated upon receipt of a spurious interrupt (an interrupt
|
|
|
|
* which is removed before the system receives the INTA sequence)
|
|
|
|
* instead of the programmed 8259 spurious interrupt vector.
|
|
|
|
*
|
|
|
|
* IMPLICATION: The spurious interrupt vector programmed in the
|
|
|
|
* 8259 is normally handled by an operating system's spurious
|
|
|
|
* interrupt handler. However, a vector of 0Fh is unknown to some
|
|
|
|
* operating systems, which would crash if this erratum occurred.
|
|
|
|
*
|
|
|
|
* In theory this could be limited to 32bit, but the handler is not
|
|
|
|
* hurting and who knows which other CPUs suffer from this.
|
|
|
|
*/
|
2008-10-04 04:00:39 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:19 +08:00
|
|
|
DEFINE_IDTENTRY(exc_device_not_available)
|
2008-09-10 03:56:02 +08:00
|
|
|
{
|
2019-01-17 20:02:05 +08:00
|
|
|
unsigned long cr0 = read_cr0();
|
2016-11-01 06:18:47 +08:00
|
|
|
|
2010-09-04 09:17:15 +08:00
|
|
|
#ifdef CONFIG_MATH_EMULATION
|
2019-01-17 20:02:05 +08:00
|
|
|
if (!boot_cpu_has(X86_FEATURE_FPU) && (cr0 & X86_CR0_EM)) {
|
2009-02-09 21:17:39 +08:00
|
|
|
struct math_emu_info info = { };
|
|
|
|
|
2016-01-26 03:41:46 +08:00
|
|
|
cond_local_irq_enable(regs);
|
2009-02-09 21:17:39 +08:00
|
|
|
|
2009-02-10 22:51:45 +08:00
|
|
|
info.regs = regs;
|
2009-02-09 21:17:39 +08:00
|
|
|
math_emulate(&info);
|
2019-10-23 20:27:10 +08:00
|
|
|
|
|
|
|
cond_local_irq_disable(regs);
|
2010-09-04 09:17:15 +08:00
|
|
|
return;
|
2008-09-10 03:56:02 +08:00
|
|
|
}
|
2010-09-04 09:17:15 +08:00
|
|
|
#endif
|
2016-11-01 06:18:47 +08:00
|
|
|
|
|
|
|
/* This should not happen. */
|
|
|
|
if (WARN(cr0 & X86_CR0_TS, "CR0.TS was set")) {
|
|
|
|
/* Try to fix it up and carry on. */
|
|
|
|
write_cr0(cr0 & ~X86_CR0_TS);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Something terrible happened, and we're better off trying
|
|
|
|
* to kill the task than getting stuck in a never-ending
|
|
|
|
* loop of #NM faults.
|
|
|
|
*/
|
2020-02-26 06:16:19 +08:00
|
|
|
die("unexpected #NM exception", regs, 0);
|
2016-11-01 06:18:47 +08:00
|
|
|
}
|
2008-09-10 03:56:02 +08:00
|
|
|
}
|
|
|
|
|
2008-10-04 04:00:39 +08:00
|
|
|
#ifdef CONFIG_X86_32
|
2020-02-26 06:16:30 +08:00
|
|
|
DEFINE_IDTENTRY_SW(iret_error)
|
2008-09-10 03:56:13 +08:00
|
|
|
{
|
|
|
|
local_irq_enable();
|
2020-02-26 06:16:30 +08:00
|
|
|
if (notify_die(DIE_TRAP, "iret exception", regs, 0,
|
2012-07-12 02:26:35 +08:00
|
|
|
X86_TRAP_IRET, SIGILL) != NOTIFY_STOP) {
|
2020-02-26 06:16:30 +08:00
|
|
|
do_trap(X86_TRAP_IRET, SIGILL, "iret exception", regs, 0,
|
2018-04-17 03:29:39 +08:00
|
|
|
ILL_BADSTK, (void __user *)NULL);
|
2012-07-12 02:26:35 +08:00
|
|
|
}
|
2019-10-23 20:27:10 +08:00
|
|
|
local_irq_disable();
|
2008-09-10 03:56:13 +08:00
|
|
|
}
|
2008-10-04 04:00:39 +08:00
|
|
|
#endif
|
2008-09-10 03:56:13 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
void __init trap_init(void)
|
|
|
|
{
|
2017-12-04 22:07:26 +08:00
|
|
|
/* Init cpu_entry_area before IST entries are set up */
|
|
|
|
setup_cpu_entry_areas();
|
|
|
|
|
2017-08-28 14:47:53 +08:00
|
|
|
idt_setup_traps();
|
2009-01-25 18:38:09 +08:00
|
|
|
|
2013-04-11 03:24:22 +08:00
|
|
|
/*
|
|
|
|
* Set the IDT descriptor to a fixed read-only location, so that the
|
|
|
|
* "sidt" instruction will not leak the location of the kernel, and
|
|
|
|
* to defend the IDT against arbitrary memory write vulnerabilities.
|
|
|
|
* It will be reloaded in cpu_init() */
|
2017-12-21 01:51:31 +08:00
|
|
|
cea_set_pte(CPU_ENTRY_AREA_RO_IDT_VADDR, __pa_symbol(idt_table),
|
|
|
|
PAGE_KERNEL_RO);
|
|
|
|
idt_descr.address = CPU_ENTRY_AREA_RO_IDT;
|
2013-04-11 03:24:22 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2008-02-26 18:15:50 +08:00
|
|
|
* Should be a barrier for any external CPU state:
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
cpu_init();
|
|
|
|
|
2017-08-28 14:47:52 +08:00
|
|
|
idt_setup_ist_traps();
|
2015-02-26 13:49:39 +08:00
|
|
|
|
2017-08-28 14:47:51 +08:00
|
|
|
idt_setup_debugidt_traps();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|