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]

Date:   Fri, 29 Mar 2019 11:45:58 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Zenghui Yu <yuzenghui@...wei.com>
Cc:     Marc Zyngier <marc.zyngier@....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 23:35:59 +0800
Zenghui Yu <yuzenghui@...wei.com> wrote:

> Hi Steven,
> 
> On 2019/3/29 22:53, Steven Rostedt wrote:
> > 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 just with function_graph tracing. Function tracing works fine.

Then we can rule out the break point issue.

> 
> > 
> > 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.  
> 
> Thanks for your explanation. I will read the code around further, and
> get back to you if there's any discovery.

Well, if it only affects function_graph tracing, then we don't need to
investigate the break point issue. If it was the break point issue, it
would cause function tracing to break too.

Also, which architecture is this for? ARM or ARM64?

-- Steve