linux-kernel - Re: [RFC PATCH 0/7] Early task context tracking

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: <9ba6e0eb-cc4c-49db-40dc-1df4b93b81ef@redhat.com>
Date:   Mon, 8 Apr 2019 14:47:33 +0200
From:   Daniel Bristot de Oliveira <bristot@...hat.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Joel Fernandes (Google)" <joel@...lfernandes.org>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Tommaso Cucinotta <tommaso.cucinotta@...tannapisa.it>,
        Romulo Silva de Oliveira <romulo.deoliveira@...c.br>,
        Clark Williams <williams@...hat.com>, X86 ML <x86@...nel.org>
Subject: Re: [RFC PATCH 0/7] Early task context tracking

On 4/4/19 2:01 AM, Andy Lutomirski wrote:
>> To resolve this problem, the set/unset of the IRQ/NMI context needs to
>> be done before the execution of the first C execution, and after its
>> return. By doing so, and using this method to identify the context in the
>> trace recursion protection, no more events are lost.
> I would much rather do the opposite: completely remove context
> tracking from the asm and, instead, stick it into the C code.  We'd
> need to make sure that the C code is totally immune from tracing,
> kprobes, etc, but it would be a nice cleanup.  And then you could fix
> this bug in C!
> 
> 

Humm... what we could do to have things in C is to set the variable right at the
begin of the C handler, e.g., do_IRQ(), and right before the return.

But by doing this we would have a problem with two things:

1) irq handler itself (e.g., do_IRQ())
2) functions/tracepoints that might run before and after the handler execution
(e.g., preemptirq tracer), but still in the IRQ context.

We can work around the first case by checking if (the function is in the
__irq_entry .text section) in the recursion control.

The second case would still be a problem. For instance, the preemptirq:
tracepoints in the preemptirq tracer would be "dropped" in the case of a
miss-identification of a recursion.

Thinking aloud: should we try to move the preemptirq tracers to the C part?

I will try to come up with a patch with this approach to see if it "works."

Thoughts?

-- Daniel