linux-kernel - Re: [RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on error

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrV1YRo8C6=VtFfrSDFAjQBs=Z6+uw-5hbus4frqAbUqGQ@mail.gmail.com>
Date:   Thu, 21 Mar 2019 11:27:00 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Juergen Gross <jgross@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Joel Fernandes <joel@...lfernandes.org>,
        He Zhe <zhe.he@...driver.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Clark Williams <williams@...hat.com>
Subject: Re: [RFC][PATCH] tracing/x86: Save CR2 before tracing irqsoff on error_entry

On Thu, Mar 21, 2019 at 11:10 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Thu, 21 Mar 2019 11:05:06 -0700
> Andy Lutomirski <luto@...capital.net> wrote:
>
> > In the long run, I think the right solution is to rewrite even more of
> > this mess in C.  We really ought to be able to put the IRQ flag
> > tracing and the context tracking into C code.
>
> And once we do that, we can work on getting the irq tracing
> incorporated into a jump_label type that we could possibly enable
> lockdep at start up, and then disable it later, even on production
> systems! That is, to be able to turn it off and bring the system back
> up to full speed.
>
> It would also allow for irq tracing too.
>
> Some inquiring minds have been asking about this ;-)
>

Well, here's pass zero at this.  Untested, because it obviously
doesn't work.  Here are just a few things that are almost certainly
wrong with it

 - The assertion that entries return with IRQs off will blow up,
because a bunch of the entries can return with IRQs on.  Needs fixing.

 - native_load_gs_index needs to be re-added as a static inline
somewhere or maybe even as a real function because of PV.  Sigh.

 - The IRQ tracing needs to be re-added.

 - Some real semantics need to be defined for precisely what code is
responsible for tracing.

 - We need some asm-callable assertions to check the following
conditions as appropriate:

 (a) that IRQ flags are currently traced as off.
 (b) that IRQ flags are currently traced to match the IRET frame.
 (c) that our context tracking is currently in good shape.  I'm not
100% sure how to define this.


 - We need to do some serious don't-instrument-me stuff to all the C
entries, since we're now in an awful context when calling them.

 - I haven't touched IRQs at all.

View attachment "entry.patch" of type "text/x-patch" (3740 bytes)