Subject: [PATCH 1/2] i386: Disallow kprobes on NMI handlers - try #2

A kprobe executes IRET early and that could cause NMI recursion and stack
corruption.

Note: This problem was originally spotted and solved by Andi Kleen in the
x86_64 architecture. This patch is an adaption of his patch for i386.

Signed-off-by: Fernando Vazquez <[email protected]>
---

diff -urNp linux-2.6.18-rc4-orig/arch/i386/kernel/entry.S linux-2.6.18-rc4/arch/i386/kernel/entry.S
--- linux-2.6.18-rc4-orig/arch/i386/kernel/entry.S 2006-08-10 20:04:10.000000000 +0900
+++ linux-2.6.18-rc4/arch/i386/kernel/entry.S 2006-08-10 20:06:11.000000000 +0900
@@ -725,7 +725,7 @@ debug_stack_correct:
* check whether we got an NMI on the debug path where the debug
* fault happened on the sysenter path.
*/
-ENTRY(nmi)
+KPROBE_ENTRY(nmi)
RING0_INT_FRAME
pushl %eax
CFI_ADJUST_CFA_OFFSET 4
diff -urNp linux-2.6.18-rc4-orig/arch/i386/kernel/nmi.c linux-2.6.18-rc4/arch/i386/kernel/nmi.c
--- linux-2.6.18-rc4-orig/arch/i386/kernel/nmi.c 2006-08-10 20:04:10.000000000 +0900
+++ linux-2.6.18-rc4/arch/i386/kernel/nmi.c 2006-08-10 20:07:06.000000000 +0900
@@ -21,6 +21,7 @@
#include <linux/sysdev.h>
#include <linux/sysctl.h>
#include <linux/percpu.h>
+#include <linux/kprobes.h>

#include <asm/smp.h>
#include <asm/nmi.h>
@@ -579,7 +580,7 @@ EXPORT_SYMBOL(touch_nmi_watchdog);

extern void die_nmi(struct pt_regs *, const char *msg);

-void nmi_watchdog_tick (struct pt_regs * regs)
+void __kprobes nmi_watchdog_tick (struct pt_regs * regs)
{

/*
diff -urNp linux-2.6.18-rc4-orig/arch/i386/kernel/traps.c linux-2.6.18-rc4/arch/i386/kernel/traps.c
--- linux-2.6.18-rc4-orig/arch/i386/kernel/traps.c 2006-08-10 20:04:11.000000000 +0900
+++ linux-2.6.18-rc4/arch/i386/kernel/traps.c 2006-08-10 20:06:11.000000000 +0900
@@ -626,7 +626,8 @@ gp_in_kernel:
}
}

-static void mem_parity_error(unsigned char reason, struct pt_regs * regs)
+static __kprobes void
+mem_parity_error(unsigned char reason, struct pt_regs * regs)
{
printk(KERN_EMERG "Uhhuh. NMI received. Dazed and confused, but trying "
"to continue\n");
@@ -637,7 +638,8 @@ static void mem_parity_error(unsigned ch
clear_mem_error(reason);
}

-static void io_check_error(unsigned char reason, struct pt_regs * regs)
+static __kprobes void
+io_check_error(unsigned char reason, struct pt_regs * regs)
{
unsigned long i;

@@ -653,7 +655,8 @@ static void io_check_error(unsigned char
outb(reason, 0x61);
}

-static void unknown_nmi_error(unsigned char reason, struct pt_regs * regs)
+static __kprobes void
+unknown_nmi_error(unsigned char reason, struct pt_regs * regs)
{
#ifdef CONFIG_MCA
/* Might actually be able to figure out what the guilty party
@@ -671,7 +674,7 @@ static void unknown_nmi_error(unsigned c

static DEFINE_SPINLOCK(nmi_print_lock);

-void die_nmi (struct pt_regs *regs, const char *msg)
+void __kprobes die_nmi(struct pt_regs *regs, const char *msg)
{
if (notify_die(DIE_NMIWATCHDOG, msg, regs, 0, 2, SIGINT) ==
NOTIFY_STOP)
@@ -703,7 +706,7 @@ void die_nmi (struct pt_regs *regs, cons
do_exit(SIGSEGV);
}

-static void default_do_nmi(struct pt_regs * regs)
+static __kprobes void default_do_nmi(struct pt_regs * regs)
{
unsigned char reason = 0;

@@ -741,14 +744,14 @@ static void default_do_nmi(struct pt_reg
reassert_nmi();
}

-static int dummy_nmi_callback(struct pt_regs * regs, int cpu)
+static __kprobes int dummy_nmi_callback(struct pt_regs * regs, int cpu)
{
return 0;
}

static nmi_callback_t nmi_callback = dummy_nmi_callback;

-fastcall void do_nmi(struct pt_regs * regs, long error_code)
+fastcall __kprobes void do_nmi(struct pt_regs * regs, long error_code)
{
int cpu;




2006-08-10 11:52:19

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH 1/2] i386: Disallow kprobes on NMI handlers - try #2

On Thursday 10 August 2006 13:36, Fernando Luis V?zquez Cao wrote:
> A kprobe executes IRET early and that could cause NMI recursion and stack
> corruption.
>
> Note: This problem was originally spotted and solved by Andi Kleen in the
> x86_64 architecture. This patch is an adaption of his patch for i386.

Originally Jan Beulich discovered these classes of bugs actually

I applied the two patches (after fixing lots of rejects because that
code had already changed a lot). But I have my doubts it is complete.

e.g. the NMI watchdog nmi code has lots of callees which you don't
handle (notifier chains, spinlocks, printks which can call practically everything, ...)

The printk in the NMI handler look pretty bogus so I just removed it.

But all the other code would be tricky. but .e.g. marking up
spinlocks would be probably not a good idea.

When we oops (call die) perhaps we can force kprobes to be disabled?

Also everybody hooking into the die chain would need to be covered too.

Probably some followon work is needed.

-Andi

Subject: Re: [PATCH 1/2] i386: Disallow kprobes on NMI handlers - try #2

On Thu, 2006-08-10 at 13:52 +0200, Andi Kleen wrote:
> On Thursday 10 August 2006 13:36, Fernando Luis Vázquez Cao wrote:
> > A kprobe executes IRET early and that could cause NMI recursion and stack
> > corruption.
> >
> > Note: This problem was originally spotted and solved by Andi Kleen in the
> > x86_64 architecture. This patch is an adaption of his patch for i386.
>
> Originally Jan Beulich discovered these classes of bugs actually
Sorry for the mistake Jan.

> I applied the two patches (after fixing lots of rejects because that
> code had already changed a lot). But I have my doubts it is complete.
>
> e.g. the NMI watchdog nmi code has lots of callees which you don't
> handle (notifier chains, spinlocks, printks which can call practically everything, ...)
>
> The printk in the NMI handler look pretty bogus so I just removed it.
I had done the same in my local repository (^-^).

> But all the other code would be tricky. but .e.g. marking up
> spinlocks would be probably not a good idea.
>
> When we oops (call die) perhaps we can force kprobes to be disabled?
>
> Also everybody hooking into the die chain would need to be covered too.
>
> Probably some followon work is needed.
Agreed. In fact I am currently working on that. I sent the previous
patches just to get started.

Thank you,

Fernando