linux-kernel - Re: [RFC PATCH] irqchip/gic-v3: Make gic_handle

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: <20190329105332.6b7fc1ae@gandalf.local.home>
Date:   Fri, 29 Mar 2019 10:53:32 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     Zenghui Yu <yuzenghui@...wei.com>, julien.thierry@....com,
        mingo@...hat.com, catalin.marinas@....com, will.deacon@....com,
        mark.rutland@....com, linux@...linux.org.uk, james.morse@....com,
        suzuki.poulose@....com, wanghaibin.wang@...wei.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] irqchip/gic-v3: Make gic_handle_irq() notrace

On Fri, 29 Mar 2019 13:58:40 +0000
Marc Zyngier <marc.zyngier@....com> wrote:

> On the other hand, if you can generate pseudo-NMIs, you could end-up
> tracing gic_handle_irq whilst being inside the tracing code with
> interrupts being notionally disabled (and that could be pretty bad).

Actually, that should still be safe. The tracing code is expected to
trace NMIs.

Now the entry of an NMI can be an issue because of the way tracing is
enabled. But this would also cause function tracing to crash, which was
not stated. Does function tracing have the same issue, or is this just
with function_graph tracing?

This is because a breakpoint is added to all the places that are going
to be traced so that the "nops" at the beginning of function calls are
going to be converted to calls to the tracer. Now that means a
breakpoint is being added at the beginning of gic_handle_irq(). I don't
know how this pseudo NMI works, but we have notrace set for do_NMI
because breakpoints at the entry (before it can fix things) causes
issues. But this still doesn't make sense because the gic_handle_irq()
call doesn't fix things up either, so other functions that are traced
by gic_handle_irq() should blow up too, which appears (by the patch)
not to be the case.

-- Steve