Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault_handler()

[Andy Lutomirski]

On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn <jannh@xxxxxxxxxx> 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@xxxxxxxxxx>
> ---
>  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
>