linux-kernel - Re: [PATCH 1/7] x86/entry: Fix #UD vs WARN more

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: <257B4193-08FB-4B3E-85E9-6C512B52C2C2@amacapital.net>
Date:   Thu, 18 Jun 2020 12:29:50 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Marco Elver <elver@...gle.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Mark Rutland <Mark.Rutland@....com>,
        Matthew Helsley <mhelsley@...are.com>,
        Steven Rostedt <rostedt@...dmis.org>, jthierry@...hat.com,
        Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH 1/7] x86/entry: Fix #UD vs WARN more


> On Jun 18, 2020, at 12:02 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> 
> On Thu, Jun 18, 2020 at 11:36:53AM -0700, Andy Lutomirski wrote:
> 
>> I wasn't imagining going far down the rabbit hole at all -- I think
>> that, at most, we should cover the path for when the fault wasn't a
>> BUG/WARN in the first place.  I admit that, for #UD in particular,
>> this isn't a big deal, but if it were a different vector, this could
>> matter.
> 
> Right, so there's 3 cases for ud2:
> 
> - WARN;  ud2,  bug_entry, recovers
> - BUG;   ud2,  bug_entry, dies
> - UBSAN; ud2, !bug_entry, dies

4. The #UD matches an extable entry. I don’t know whether this ever happens for real.

The failure is still a bit farfetched: we’d need an extable to hit in an inconsistent state where we blow up due to a lack of entry handling.

> 
> Nothing else should be generating ud2 instructions, any other #UD goes
> into handle_invalid_op() -> do_error_trap() -> ... -> die().
> 
> [ while there, we should probably restructure do_trap() to have
>  cond_local_irq_enable() _after_ do_trap_no_signal(). ]
> 
> We could probably change is_valid_bugaddr() to not use
> probe_kernel_address(), because if it couldn't read the instruction,
> we'd not be getting #UD in the first place.
> 
> If we've gotten rid of probe_kernel_address() we can noinstr/inline that
> and then we can only call into report_bug() IFF ud2.
> 
> Does that make things 'better' ? This can only go realy bad if there's a
> 1 byte instruction that triggers #UD, but I think that was ruled out.
> 
> 
> ---
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index c26751e303f1..275a621f1aff 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -91,10 +91,7 @@ int is_valid_bugaddr(unsigned long addr)
>    if (addr < TASK_SIZE_MAX)
>        return 0;
> 
> -    if (probe_kernel_address((unsigned short *)addr, ud))
> -        return 0;
> -
> -    return ud == INSN_UD0 || ud == INSN_UD2;
> +    return *(unsigned short *)addr == INSN_UD2;
> }

I’m okay with this, at least until we get PKRS or kernel XO memory. But probe_kernel_addr() would be wrong then, too.  We need probe_kernel_text().

But I think you might need some IRQ fiddling. With your patch, a WARN with IRQs on will execute the printk code with IRQs off without lockstep handling, and an appropriately configured debugging kernel may get a recursive splat.  Or if irq tracing somehow notices that IRQs got turned off, the warning recovery might return back to an IF=1 context with IRQs traced as off.

So maybe also do an untraced cond_local_irq_enable()?  After all, if we’re trying to report a bug from IRQs on, it should be okay to have IRQs on while reporting it. It might even work better than having IRQs off.

> 
> static nokprobe_inline int
> @@ -220,15 +217,17 @@ static noinstr bool handle_bug(struct pt_regs *regs)
> {
>    bool handled = false;
> 
> -    /*
> -     * All lies, just get the WARN/BUG out.
> -     */
> -    instrumentation_begin();
> -    if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
> -        regs->ip += LEN_UD2;
> -        handled = true;
> +    if (is_valid_bugaddr(regs->ip)) {
> +        /*
> +         * All lies, just get the WARN/BUG out.
> +         */
> +        instrumentation_begin();
> +        if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
> +            regs->ip += LEN_UD2;
> +            handled = true;
> +        }
> +        instrumentation_end();
>    }
> -    instrumentation_end();
> 
>    return handled;
> }