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>
|
2020-09-07 21:15:46 +08:00
|
|
|
#include <asm/realmode.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>
|
x86/traps: Attempt to fixup exceptions in vDSO before signaling
vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup. For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal. This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.
Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information. Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.
Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal. Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Link: https://lkml.kernel.org/r/20201112220135.165028-19-jarkko@kernel.org
2020-11-13 06:01:29 +08:00
|
|
|
#include <asm/vdso.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/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();
|
|
|
|
}
|
|
|
|
|
2020-06-16 19:28:36 +08:00
|
|
|
__always_inline int is_valid_bugaddr(unsigned long addr)
|
2017-02-02 21:43:51 +08:00
|
|
|
{
|
|
|
|
if (addr < TASK_SIZE_MAX)
|
|
|
|
return 0;
|
|
|
|
|
2020-06-16 19:28:36 +08:00
|
|
|
/*
|
|
|
|
* We got #UD, if the text isn't readable we'd have gotten
|
|
|
|
* a different exception.
|
|
|
|
*/
|
|
|
|
return *(unsigned short *)addr == INSN_UD2;
|
2017-02-02 21:43:51 +08:00
|
|
|
}
|
|
|
|
|
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);
|
x86/traps: Attempt to fixup exceptions in vDSO before signaling
vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup. For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal. This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.
Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information. Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.
Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal. Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Link: https://lkml.kernel.org/r/20201112220135.165028-19-jarkko@kernel.org
2020-11-13 06:01:29 +08:00
|
|
|
} else {
|
|
|
|
if (fixup_vdso_exception(regs, trapnr, error_code, 0))
|
|
|
|
return 0;
|
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
|
|
|
|
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)
|
|
|
|
{
|
2020-10-12 21:11:47 +08:00
|
|
|
do_error_trap(regs, 0, "divide error", X86_TRAP_DE, SIGFPE,
|
2020-02-26 06:16:14 +08:00
|
|
|
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));
|
|
|
|
}
|
|
|
|
|
2020-06-16 19:28:36 +08:00
|
|
|
static noinstr bool handle_bug(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
bool handled = false;
|
|
|
|
|
|
|
|
if (!is_valid_bugaddr(regs->ip))
|
|
|
|
return handled;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* All lies, just get the WARN/BUG out.
|
|
|
|
*/
|
|
|
|
instrumentation_begin();
|
|
|
|
/*
|
|
|
|
* Since we're emulating a CALL with exceptions, restore the interrupt
|
|
|
|
* state to what it was at the exception site.
|
|
|
|
*/
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
raw_local_irq_enable();
|
|
|
|
if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
|
|
|
|
regs->ip += LEN_UD2;
|
|
|
|
handled = true;
|
|
|
|
}
|
|
|
|
if (regs->flags & X86_EFLAGS_IF)
|
|
|
|
raw_local_irq_disable();
|
|
|
|
instrumentation_end();
|
|
|
|
|
|
|
|
return handled;
|
|
|
|
}
|
|
|
|
|
2020-06-12 11:26:38 +08:00
|
|
|
DEFINE_IDTENTRY_RAW(exc_invalid_op)
|
2020-02-26 06:16:18 +08:00
|
|
|
{
|
2020-07-23 06:00:08 +08:00
|
|
|
irqentry_state_t state;
|
2020-06-12 11:26:38 +08:00
|
|
|
|
|
|
|
/*
|
2020-06-16 19:28:36 +08:00
|
|
|
* We use UD2 as a short encoding for 'CALL __WARN', as such
|
|
|
|
* handle it before exception entry to avoid recursive WARN
|
|
|
|
* in case exception entry is the one triggering WARNs.
|
2020-06-12 11:26:38 +08:00
|
|
|
*/
|
2020-06-16 19:28:36 +08:00
|
|
|
if (!user_mode(regs) && handle_bug(regs))
|
|
|
|
return;
|
2020-06-12 11:26:38 +08:00
|
|
|
|
2020-07-23 06:00:08 +08:00
|
|
|
state = irqentry_enter(regs);
|
2020-06-12 11:26:38 +08:00
|
|
|
instrumentation_begin();
|
2020-02-26 06:16:18 +08:00
|
|
|
handle_invalid_op(regs);
|
2020-06-12 11:26:38 +08:00
|
|
|
instrumentation_end();
|
2020-07-23 06:00:08 +08:00
|
|
|
irqentry_exit(regs, state);
|
2020-02-26 06:16:18 +08:00
|
|
|
}
|
|
|
|
|
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))
|
2020-12-23 01:40:10 +08:00
|
|
|
goto out;
|
2020-01-27 04:05:35 +08:00
|
|
|
|
|
|
|
do_trap(X86_TRAP_AC, SIGBUS, "alignment check", regs,
|
|
|
|
error_code, BUS_ADRALN, NULL);
|
2020-07-09 03:28:05 +08:00
|
|
|
|
2020-12-23 01:40:10 +08:00
|
|
|
out:
|
2020-07-09 03:28:05 +08:00
|
|
|
local_irq_disable();
|
2020-01-27 04:05:35 +08:00
|
|
|
}
|
|
|
|
|
2016-08-11 17:35:23 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
2016-08-31 08:27:57 +08:00
|
|
|
__visible void __noreturn handle_stack_overflow(const char *message,
|
|
|
|
struct pt_regs *regs,
|
|
|
|
unsigned long fault_address)
|
2016-08-11 17:35:23 +08:00
|
|
|
{
|
|
|
|
printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is %p..%p)\n",
|
|
|
|
(void *)fault_address, current->stack,
|
|
|
|
(char *)current->stack + THREAD_SIZE - 1);
|
|
|
|
die(message, regs, 0);
|
|
|
|
|
|
|
|
/* Be absolutely certain we don't return. */
|
2018-10-27 06:20:04 +08:00
|
|
|
panic("%s", message);
|
2016-08-11 17:35:23 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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.
|
2020-02-26 06:33:31 +08:00
|
|
|
*
|
|
|
|
* The 32bit #DF shim provides CR2 already as an argument. On 64bit it needs
|
|
|
|
* to be read before doing anything else.
|
2019-11-21 15:06:41 +08:00
|
|
|
*/
|
2020-02-26 06:33:31 +08:00
|
|
|
DEFINE_IDTENTRY_DF(exc_double_fault)
|
2008-10-04 04:00:39 +08:00
|
|
|
{
|
|
|
|
static const char str[] = "double fault";
|
|
|
|
struct task_struct *tsk = current;
|
|
|
|
|
2020-05-25 15:42:41 +08:00
|
|
|
#ifdef CONFIG_VMAP_STACK
|
2020-02-26 06:33:31 +08:00
|
|
|
unsigned long address = read_cr2();
|
|
|
|
#endif
|
|
|
|
|
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
|
2021-03-18 22:28:01 +08:00
|
|
|
* we won't enable interrupts or schedule before we invoke
|
2017-12-04 22:07:22 +08:00
|
|
|
* 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-11-03 04:53:16 +08:00
|
|
|
irqentry_nmi_enter(regs);
|
2020-02-26 06:33:31 +08:00
|
|
|
instrumentation_begin();
|
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.
|
|
|
|
*/
|
2020-02-26 06:33:31 +08:00
|
|
|
if ((unsigned long)task_stack_page(tsk) - 1 - address < PAGE_SIZE) {
|
|
|
|
handle_stack_overflow("kernel stack overflow (double-fault)",
|
|
|
|
regs, address);
|
|
|
|
}
|
2016-08-11 17:35:23 +08:00
|
|
|
#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.");
|
2020-02-26 06:33:31 +08:00
|
|
|
instrumentation_end();
|
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;
|
2020-11-17 01:38:45 +08:00
|
|
|
int ret;
|
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
|
|
|
|
2020-06-17 15:37:53 +08:00
|
|
|
if (copy_from_kernel_nofault(insn_buf, (void *)regs->ip,
|
|
|
|
MAX_INSN_SIZE))
|
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
|
|
|
return GP_NO_HINT;
|
|
|
|
|
2021-03-26 23:12:00 +08:00
|
|
|
ret = insn_decode_kernel(&insn, insn_buf);
|
2020-11-17 01:38:45 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return GP_NO_HINT;
|
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
|
|
|
|
|
|
|
*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
|
|
|
|
x86/traps: Attempt to fixup exceptions in vDSO before signaling
vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup. For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal. This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.
Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information. Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.
Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal. Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Link: https://lkml.kernel.org/r/20201112220135.165028-19-jarkko@kernel.org
2020-11-13 06:01:29 +08:00
|
|
|
if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
|
2021-04-09 01:28:33 +08:00
|
|
|
goto exit;
|
x86/traps: Attempt to fixup exceptions in vDSO before signaling
vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup. For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal. This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.
Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information. Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.
Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal. Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Link: https://lkml.kernel.org/r/20201112220135.165028-19-jarkko@kernel.org
2020-11-13 06:01:29 +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
|
|
|
}
|
|
|
|
|
2020-03-05 23:09:52 +08:00
|
|
|
static bool do_int3(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
|
|
|
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
|
|
|
|
if (kgdb_ll_trap(DIE_INT3, "int3", regs, 0, X86_TRAP_BP,
|
|
|
|
SIGTRAP) == NOTIFY_STOP)
|
|
|
|
return true;
|
|
|
|
#endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
|
|
|
|
|
|
|
|
#ifdef CONFIG_KPROBES
|
|
|
|
if (kprobe_int3_handler(regs))
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
res = notify_die(DIE_INT3, "int3", regs, 0, X86_TRAP_BP, SIGTRAP);
|
|
|
|
|
|
|
|
return res == NOTIFY_STOP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void do_int3_user(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
if (do_int3(regs))
|
|
|
|
return;
|
|
|
|
|
|
|
|
cond_local_irq_enable(regs);
|
|
|
|
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, 0, 0, NULL);
|
|
|
|
cond_local_irq_disable(regs);
|
|
|
|
}
|
|
|
|
|
2020-02-26 06:16:16 +08:00
|
|
|
DEFINE_IDTENTRY_RAW(exc_int3)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2020-02-20 20:28:06 +08:00
|
|
|
/*
|
|
|
|
* poke_int3_handler() is completely self contained code; it does (and
|
|
|
|
* must) *NOT* call out to anything, lest it hits upon yet another
|
|
|
|
* INT3.
|
|
|
|
*/
|
2013-07-23 16:09:28 +08:00
|
|
|
if (poke_int3_handler(regs))
|
|
|
|
return;
|
|
|
|
|
2015-07-24 06:37:48 +08:00
|
|
|
/*
|
2020-07-23 06:00:06 +08:00
|
|
|
* irqentry_enter_from_user_mode() uses static_branch_{,un}likely()
|
|
|
|
* and therefore can trigger INT3, hence poke_int3_handler() must
|
|
|
|
* be done before. If the entry came from kernel mode, then use
|
|
|
|
* nmi_enter() because the INT3 could have been hit in any context
|
|
|
|
* including NMI.
|
2015-07-24 06:37:48 +08:00
|
|
|
*/
|
2020-03-05 23:09:52 +08:00
|
|
|
if (user_mode(regs)) {
|
2020-07-23 06:00:06 +08:00
|
|
|
irqentry_enter_from_user_mode(regs);
|
2020-03-05 23:09:52 +08:00
|
|
|
instrumentation_begin();
|
|
|
|
do_int3_user(regs);
|
|
|
|
instrumentation_end();
|
2020-07-23 06:00:06 +08:00
|
|
|
irqentry_exit_to_user_mode(regs);
|
2020-03-05 23:09:52 +08:00
|
|
|
} else {
|
2020-11-03 04:53:16 +08:00
|
|
|
irqentry_state_t irq_state = irqentry_nmi_enter(regs);
|
|
|
|
|
2020-03-05 23:09:52 +08:00
|
|
|
instrumentation_begin();
|
|
|
|
if (!do_int3(regs))
|
|
|
|
die("int3", regs, 0);
|
|
|
|
instrumentation_end();
|
2020-11-03 04:53:16 +08:00
|
|
|
irqentry_nmi_exit(regs, irq_state);
|
2020-03-05 23:09:52 +08:00
|
|
|
}
|
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
|
|
|
|
2020-09-07 21:15:46 +08:00
|
|
|
#ifdef CONFIG_AMD_MEM_ENCRYPT
|
|
|
|
asmlinkage __visible noinstr struct pt_regs *vc_switch_off_ist(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
unsigned long sp, *stack;
|
|
|
|
struct stack_info info;
|
|
|
|
struct pt_regs *regs_ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In the SYSCALL entry path the RSP value comes from user-space - don't
|
|
|
|
* trust it and switch to the current kernel stack
|
|
|
|
*/
|
2021-03-03 22:17:12 +08:00
|
|
|
if (ip_within_syscall_gap(regs)) {
|
2020-09-07 21:15:46 +08:00
|
|
|
sp = this_cpu_read(cpu_current_top_of_stack);
|
|
|
|
goto sync;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* From here on the RSP value is trusted. Now check whether entry
|
|
|
|
* happened from a safe stack. Not safe are the entry or unknown stacks,
|
|
|
|
* use the fall-back stack instead in this case.
|
|
|
|
*/
|
|
|
|
sp = regs->sp;
|
|
|
|
stack = (unsigned long *)sp;
|
|
|
|
|
|
|
|
if (!get_stack_info_noinstr(stack, current, &info) || info.type == STACK_TYPE_ENTRY ||
|
|
|
|
info.type >= STACK_TYPE_EXCEPTION_LAST)
|
|
|
|
sp = __this_cpu_ist_top_va(VC2);
|
|
|
|
|
|
|
|
sync:
|
|
|
|
/*
|
|
|
|
* Found a safe stack - switch to it as if the entry didn't happen via
|
|
|
|
* IST stack. The code below only copies pt_regs, the real switch happens
|
|
|
|
* in assembly code.
|
|
|
|
*/
|
|
|
|
sp = ALIGN_DOWN(sp, 8) - sizeof(*regs_ret);
|
|
|
|
|
|
|
|
regs_ret = (struct pt_regs *)sp;
|
|
|
|
*regs_ret = *regs;
|
|
|
|
|
|
|
|
return regs_ret;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
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. */
|
2020-06-18 00:21:16 +08:00
|
|
|
__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-06-18 00:21:16 +08:00
|
|
|
__memcpy(&tmp, s, offsetof(struct bad_iret_stack, regs.ip));
|
2020-03-26 02:53:38 +08:00
|
|
|
|
|
|
|
/* Update the entry stack */
|
2020-06-18 00:21:16 +08:00
|
|
|
__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
|
|
|
|
}
|
|
|
|
|
2020-09-02 21:25:51 +08:00
|
|
|
static __always_inline unsigned long debug_read_clear_dr6(void)
|
2020-04-07 03:02:56 +08:00
|
|
|
{
|
2020-09-02 21:25:51 +08:00
|
|
|
unsigned long dr6;
|
2020-04-07 03:02:56 +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.
|
|
|
|
*/
|
2020-09-02 21:25:51 +08:00
|
|
|
get_debugreg(dr6, 6);
|
2020-09-02 21:26:01 +08:00
|
|
|
set_debugreg(DR6_RESERVED, 6);
|
|
|
|
dr6 ^= DR6_RESERVED; /* Flip to positive polarity */
|
2020-04-07 03:02:56 +08:00
|
|
|
|
2020-09-02 21:25:51 +08:00
|
|
|
return dr6;
|
2020-04-07 03:02:56 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
*/
|
2020-09-02 21:25:57 +08:00
|
|
|
|
|
|
|
static bool notify_debug(struct pt_regs *regs, unsigned long *dr6)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2020-09-02 21:26:02 +08:00
|
|
|
/*
|
|
|
|
* Notifiers will clear bits in @dr6 to indicate the event has been
|
|
|
|
* consumed - hw_breakpoint_handler(), single_stop_cont().
|
|
|
|
*
|
|
|
|
* Notifiers will set bits in @virtual_dr6 to indicate the desire
|
|
|
|
* for signals - ptrace_triggered(), kgdb_hw_overflow_handler().
|
|
|
|
*/
|
2020-09-02 21:25:56 +08:00
|
|
|
if (notify_die(DIE_DEBUG, "debug", regs, (long)dr6, 0, SIGTRAP) == NOTIFY_STOP)
|
|
|
|
return true;
|
2008-10-01 00:41:37 +08:00
|
|
|
|
2020-09-02 21:25:56 +08:00
|
|
|
return false;
|
2020-02-26 06:33:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void exc_debug_kernel(struct pt_regs *regs,
|
|
|
|
unsigned long dr6)
|
|
|
|
{
|
2020-09-02 21:25:51 +08:00
|
|
|
/*
|
|
|
|
* Disable breakpoints during exception handling; recursive exceptions
|
|
|
|
* are exceedingly 'fun'.
|
|
|
|
*
|
|
|
|
* Since this function is NOKPROBE, and that also applies to
|
|
|
|
* HW_BREAKPOINT_X, we can't hit a breakpoint before this (XXX except a
|
|
|
|
* HW_BREAKPOINT_W on our stack)
|
|
|
|
*
|
|
|
|
* Entry text is excluded for HW_BP_X and cpu_entry_area, which
|
|
|
|
* includes the entry stack is excluded for everything.
|
|
|
|
*/
|
|
|
|
unsigned long dr7 = local_db_save();
|
2020-11-03 04:53:16 +08:00
|
|
|
irqentry_state_t irq_state = irqentry_nmi_enter(regs);
|
2020-05-22 04:05:51 +08:00
|
|
|
instrumentation_begin();
|
2020-05-05 01:56:26 +08:00
|
|
|
|
2020-07-04 01:02:55 +08:00
|
|
|
/*
|
|
|
|
* If something gets miswired and we end up here for a user mode
|
|
|
|
* #DB, we will malfunction.
|
|
|
|
*/
|
|
|
|
WARN_ON_ONCE(user_mode(regs));
|
|
|
|
|
2020-10-27 17:15:05 +08:00
|
|
|
if (test_thread_flag(TIF_BLOCKSTEP)) {
|
|
|
|
/*
|
|
|
|
* The SDM says "The processor clears the BTF flag when it
|
|
|
|
* generates a debug exception." but PTRACE_BLOCKSTEP requested
|
|
|
|
* it for userspace, but we just took a kernel #DB, so re-set
|
|
|
|
* BTF.
|
|
|
|
*/
|
|
|
|
unsigned long debugctl;
|
|
|
|
|
|
|
|
rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
|
|
|
|
debugctl |= DEBUGCTLMSR_BTF;
|
|
|
|
wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
|
|
|
|
}
|
|
|
|
|
2020-05-05 01:56:26 +08:00
|
|
|
/*
|
|
|
|
* Catch SYSENTER with TF set and clear DR_STEP. If this hit a
|
|
|
|
* watchpoint at the same time then that will still be handled.
|
|
|
|
*/
|
|
|
|
if ((dr6 & DR_STEP) && is_sysenter_singlestep(regs))
|
|
|
|
dr6 &= ~DR_STEP;
|
|
|
|
|
2020-09-02 21:25:54 +08:00
|
|
|
/*
|
|
|
|
* The kernel doesn't use INT1
|
|
|
|
*/
|
|
|
|
if (!dr6)
|
|
|
|
goto out;
|
|
|
|
|
2020-09-02 21:25:57 +08:00
|
|
|
if (notify_debug(regs, &dr6))
|
2020-09-02 21:25:56 +08:00
|
|
|
goto out;
|
|
|
|
|
2020-09-02 21:25:58 +08:00
|
|
|
/*
|
|
|
|
* The kernel doesn't use TF single-step outside of:
|
|
|
|
*
|
|
|
|
* - Kprobes, consumed through kprobe_debug_handler()
|
|
|
|
* - KGDB, consumed through notify_debug()
|
|
|
|
*
|
|
|
|
* So if we get here with DR_STEP set, something is wonky.
|
|
|
|
*
|
|
|
|
* A known way to trigger this is through QEMU's GDB stub,
|
|
|
|
* which leaks #DB into the guest and causes IST recursion.
|
|
|
|
*/
|
2020-09-02 21:26:02 +08:00
|
|
|
if (WARN_ON_ONCE(dr6 & DR_STEP))
|
2020-09-02 21:25:56 +08:00
|
|
|
regs->flags &= ~X86_EFLAGS_TF;
|
2020-09-02 21:25:53 +08:00
|
|
|
out:
|
2020-05-22 04:05:51 +08:00
|
|
|
instrumentation_end();
|
2020-11-03 04:53:16 +08:00
|
|
|
irqentry_nmi_exit(regs, irq_state);
|
2020-09-02 21:25:51 +08:00
|
|
|
|
|
|
|
local_db_restore(dr7);
|
2020-02-26 06:33:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void exc_debug_user(struct pt_regs *regs,
|
|
|
|
unsigned long dr6)
|
|
|
|
{
|
2020-09-02 21:25:57 +08:00
|
|
|
bool icebp;
|
|
|
|
|
2020-07-04 01:02:55 +08:00
|
|
|
/*
|
|
|
|
* If something gets miswired and we end up here for a kernel mode
|
|
|
|
* #DB, we will malfunction.
|
|
|
|
*/
|
|
|
|
WARN_ON_ONCE(!user_mode(regs));
|
|
|
|
|
2020-09-02 21:25:51 +08:00
|
|
|
/*
|
|
|
|
* NB: We can't easily clear DR7 here because
|
2020-11-03 04:53:16 +08:00
|
|
|
* irqentry_exit_to_usermode() can invoke ptrace, schedule, access
|
2020-09-02 21:25:51 +08:00
|
|
|
* user memory, etc. This means that a recursive #DB is possible. If
|
|
|
|
* this happens, that #DB will hit exc_debug_kernel() and clear DR7.
|
|
|
|
* Since we're not on the IST stack right now, everything will be
|
|
|
|
* fine.
|
|
|
|
*/
|
|
|
|
|
2020-07-23 06:00:06 +08:00
|
|
|
irqentry_enter_from_user_mode(regs);
|
2020-06-03 19:40:20 +08:00
|
|
|
instrumentation_begin();
|
2020-05-05 01:56:26 +08:00
|
|
|
|
2020-10-27 17:15:06 +08:00
|
|
|
/*
|
2020-10-28 02:33:30 +08:00
|
|
|
* Start the virtual/ptrace DR6 value with just the DR_STEP mask
|
|
|
|
* of the real DR6. ptrace_triggered() will set the DR_TRAPn bits.
|
|
|
|
*
|
|
|
|
* Userspace expects DR_STEP to be visible in ptrace_get_debugreg(6)
|
|
|
|
* even if it is not the result of PTRACE_SINGLESTEP.
|
2020-10-27 17:15:06 +08:00
|
|
|
*/
|
2020-10-28 02:33:30 +08:00
|
|
|
current->thread.virtual_dr6 = (dr6 & DR_STEP);
|
2020-10-27 17:15:06 +08:00
|
|
|
|
2020-10-27 17:15:05 +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_thread_flag(TIF_BLOCKSTEP);
|
|
|
|
|
2020-09-02 21:25:57 +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.
|
|
|
|
*/
|
|
|
|
icebp = !dr6;
|
|
|
|
|
|
|
|
if (notify_debug(regs, &dr6))
|
|
|
|
goto out;
|
2020-05-27 21:50:29 +08:00
|
|
|
|
2020-09-02 21:25:57 +08:00
|
|
|
/* It's safe to allow irq's after DR6 has been saved */
|
|
|
|
local_irq_enable();
|
|
|
|
|
|
|
|
if (v8086_mode(regs)) {
|
|
|
|
handle_vm86_trap((struct kernel_vm86_regs *)regs, 0, X86_TRAP_DB);
|
|
|
|
goto out_irq;
|
|
|
|
}
|
|
|
|
|
2021-03-22 21:53:24 +08:00
|
|
|
/* #DB for bus lock can only be triggered from userspace. */
|
|
|
|
if (dr6 & DR_BUS_LOCK)
|
|
|
|
handle_bus_lock(regs);
|
|
|
|
|
2020-09-02 21:26:02 +08:00
|
|
|
/* Add the virtual_dr6 bits for signals. */
|
|
|
|
dr6 |= current->thread.virtual_dr6;
|
2020-09-02 21:25:57 +08:00
|
|
|
if (dr6 & (DR_STEP | DR_TRAP_BITS) || icebp)
|
|
|
|
send_sigtrap(regs, 0, get_si_code(dr6));
|
|
|
|
|
|
|
|
out_irq:
|
|
|
|
local_irq_disable();
|
|
|
|
out:
|
2020-06-03 19:40:20 +08:00
|
|
|
instrumentation_end();
|
2020-07-23 06:00:06 +08:00
|
|
|
irqentry_exit_to_user_mode(regs);
|
2020-02-26 06:33:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_X86_64
|
|
|
|
/* IST stack entry */
|
|
|
|
DEFINE_IDTENTRY_DEBUG(exc_debug)
|
|
|
|
{
|
2020-09-02 21:25:51 +08:00
|
|
|
exc_debug_kernel(regs, debug_read_clear_dr6());
|
2020-02-26 06:33:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* User entry, runs on regular task stack */
|
|
|
|
DEFINE_IDTENTRY_DEBUG_USER(exc_debug)
|
|
|
|
{
|
2020-09-02 21:25:51 +08:00
|
|
|
exc_debug_user(regs, debug_read_clear_dr6());
|
2020-02-26 06:33:29 +08:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
/* 32 bit does not have separate entry points. */
|
2020-07-04 01:02:56 +08:00
|
|
|
DEFINE_IDTENTRY_RAW(exc_debug)
|
2020-02-26 06:33:29 +08:00
|
|
|
{
|
2020-09-02 21:25:51 +08:00
|
|
|
unsigned long dr6 = debug_read_clear_dr6();
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-02-26 06:33:26 +08:00
|
|
|
if (user_mode(regs))
|
2020-02-26 06:33:29 +08:00
|
|
|
exc_debug_user(regs, dr6);
|
2020-02-26 06:33:26 +08:00
|
|
|
else
|
2020-02-26 06:33:29 +08:00
|
|
|
exc_debug_kernel(regs, dr6);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2020-02-26 06:33:29 +08:00
|
|
|
#endif
|
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
|
|
|
|
x86/traps: Attempt to fixup exceptions in vDSO before signaling
vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup. For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal. This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.
Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information. Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.
Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal. Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Link: https://lkml.kernel.org/r/20201112220135.165028-19-jarkko@kernel.org
2020-11-13 06:01:29 +08:00
|
|
|
if (fixup_vdso_exception(regs, trapnr, 0, 0))
|
2021-04-09 01:28:33 +08:00
|
|
|
goto exit;
|
x86/traps: Attempt to fixup exceptions in vDSO before signaling
vDSO functions can now leverage an exception fixup mechanism similar to
kernel exception fixup. For vDSO exception fixup, the initial user is
Intel's Software Guard Extensions (SGX), which will wrap the low-level
transitions to/from the enclave, i.e. EENTER and ERESUME instructions,
in a vDSO function and leverage fixup to intercept exceptions that would
otherwise generate a signal. This allows the vDSO wrapper to return the
fault information directly to its caller, obviating the need for SGX
applications and libraries to juggle signal handlers.
Attempt to fixup vDSO exceptions immediately prior to populating and
sending signal information. Except for the delivery mechanism, an
exception in a vDSO function should be treated like any other exception
in userspace, e.g. any fault that is successfully handled by the kernel
should not be directly visible to userspace.
Although it's debatable whether or not all exceptions are of interest to
enclaves, defer to the vDSO fixup to decide whether to do fixup or
generate a signal. Future users of vDSO fixup, if there ever are any,
will undoubtedly have different requirements than SGX enclaves, e.g. the
fixup vs. signal logic can be made function specific if/when necessary.
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Jethro Beekman <jethro@fortanix.com>
Link: https://lkml.kernel.org/r/20201112220135.165028-19-jarkko@kernel.org
2020-11-13 06:01:29 +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();
|
|
|
|
|
2020-09-07 21:15:42 +08:00
|
|
|
/* Init GHCB memory pages when running as an SEV-ES guest */
|
|
|
|
sev_es_init_vc_handling();
|
|
|
|
|
2017-08-28 14:47:53 +08:00
|
|
|
idt_setup_traps();
|
2009-01-25 18:38:09 +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();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|