linux-kernel - Re: [REGRESSION 5.8] x86/entry: DR0 break-on-write not working

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]

Date:   Wed, 19 Aug 2020 17:14:18 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, Kyle Huey <me@...ehuey.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Andy Lutomirski <luto@...nel.org>,
        "Robert O'Callahan" <rocallahan@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Brian Gerst <brgerst@...il.com>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Will Deacon <will@...nel.org>
Subject: Re: [REGRESSION 5.8] x86/entry: DR0 break-on-write not working

On Wed, Aug 19, 2020 at 3:47 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> On Wed, Aug 19, 2020 at 11:35:34PM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 19, 2020 at 12:28:16PM -0700, Kyle Huey wrote:
> >
> > > > I'm guess that is not the expected outcome, is that the same failure you
> > > > saw?
> > >
> > > Yes. Is status also 0x4d00 for you?
> >
> > Indeed.
> >
> > > The program is expected to complete with no assertions firing.
> >
> > When I comment out the break-on-exec test, the break-on-write test
> > succeeds.
> >
> > When I add a few printk()'s to our #DB handler (6) the program will
> > magically work again.
>
> I added some trace_printk()'s and I think the #DB handler is calling
> schedule????
>
> exc_debug_user()
>   irqentry_exit_to_user_mode()
>     exit_to_user_mode_prepare()
>       exit_to_user_mode_loop()
>         schedule()
>
> So #DB schedules out, then the process scheduls in and tells ptrace to
> set the data breakpoint in DR7.  Then the #DB handler schedules back in
> and overwrites DR7 with the original value.
>
> What amazes me is that it successfully schedules back to the end of the
> #DB handler finish and everything keeps working.
>
> Do we not have assertions in the scheduler to catch this?

You almost nailed it.

I'm pretty sure you have the buggy sequence of events right, but for
the wrong reason.  There's nothing wrong with scheduling when
delivering SIGTRAP, but it's definitely wrong to blindly save and
restore DR7 around scheduling and around ptrace invocations.  Remember
this is an entry from user mode, so it runs on the user stack.

Patch coming.

--Andy