Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUeRA63Vt_LBOGmUHc_M9gc3J7+ewK6j+sB8P=9ijk7ag@mail.gmail.com>
Date: Mon, 27 Aug 2018 12:02:19 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Jann Horn <jannh@...gle.com>, Masami Hiramatsu <mhiramat@...nel.org>, 
	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>, 
	Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>, "David S. Miller" <davem@...emloft.net>
Cc: Kees Cook <keescook@...omium.org>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>, Andy Lutomirski <luto@...nel.org>, 
	Kernel Hardening <kernel-hardening@...ts.openwall.com>, Tony Luck <tony.luck@...el.com>, 
	Borislav Petkov <bp@...en8.de>, LKML <linux-kernel@...r.kernel.org>, 
	Dmitry Vyukov <dvyukov@...gle.com>, linux-edac <linux-edac@...r.kernel.org>
Subject: Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler()

On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn <jannh@...gle.com> wrote:
> This removes the call into exception fixup that was added in
> commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
> x86_64").
>
> On X86, kprobe_fault_handler() is called from two places:
> do_general_protection() (for #GP) and kprobes_fault() (for #PF).
> In both paths, the fixup_exception() call in the kprobe fault handler is
> redundant.
>
> For #GP, fixup_exception() is called immediately before
> kprobe_fault_handler() is invoked - if someone wanted to fix up our #GP,
> they've already done so, no need to try again. (This assumes that the
> kprobe's fault handler isn't going to do something crazy like changing RIP
> so that it suddenly points to an instruction that does userspace access.)

This needs review by someone who understands kprobes better than I do.
What happens if someone puts a kprobe on a uaccess instruction and the
uaccess subsequently faults?

>
> For #PF on a kernel address from kernel space, after the kprobe fault
> handler has run, we'll go into no_context(), which calls fixup_exception().
>
> Signed-off-by: Jann Horn <jannh@...gle.com>
> ---
>  arch/x86/kernel/kprobes/core.c | 7 -------
>  1 file changed, 7 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 467ac22691b0..7315ac202aad 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -1021,13 +1021,6 @@ int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
>                 if (cur->fault_handler && cur->fault_handler(cur, regs, trapnr))
>                         return 1;
>
> -               /*
> -                * In case the user-specified fault handler returned
> -                * zero, try to fix up.
> -                */
> -               if (fixup_exception(regs, trapnr))
> -                       return 1;
> -
>                 /* fixup routine could not handle it. */
>         }
>
> --
> 2.19.0.rc0.228.g281dcd1b4d0-goog
>

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.