linux-kernel - Re: [PATCH v2 3/7] x86: stop calling fixup_exception() from kprobe_fault

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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
>