linux-kernel - Re: [PATCH 1/4] genirq: Provide basic NMI management for interrupt lines

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:   Thu, 2 Aug 2018 08:55:49 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Marc Zyngier <marc.zyngier@....com>
cc:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
        Julien Thierry <julien.thierry@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 1/4] genirq: Provide basic NMI management for interrupt
 lines

On Thu, 2 Aug 2018, Marc Zyngier wrote:
> On Thu, 02 Aug 2018 03:03:20 +0100,
> Ricardo Neri <ricardo.neri-calderon@...ux.intel.com> wrote:
> > On Wed, Aug 01, 2018 at 04:09:59PM +0100, Julien Thierry wrote:
> > > >
> > > >I don't think this works in x86 because the local APIC irq_chip is the
> > > >root of the hierarchy; the rest of the irq_chips are children of it.
> > > >Furthermore, the delivery mode (i.e., regular interrupt vs NMI) is set in
> > > >these children controllers, either MSI or interrupt remapping.
> > > >
> > > >Instead, could it be possible to determine if NMI mode is supported by
> > > >checking if any of the parents of the irq_data supports NMI mode? If it
> > > >has to be the root, perhaps a flag can indicate irq_supports_nmi() about
> > > >this restriction.
> > > >
> > > 
> > > I see, I'm not very sure how to deal with the semantics here. Does it make
> > > sense for an irqchip to be able to deliver NMIs if its parent doesn't?
> > 
> > I think it does not make sense. 
> > 
> > > 
> > > If we want to handle NMI in and irqchip hierachy, shouldn't all irqchips
> > > between the one delivering the NMI and the root irqchip also be able to
> > > deliver NMIs? (Or is it the other way around and an irqchip can deliver an
> > > NMI if all its children irqchip are also able to deliver an NMI?)
> > 
> > At least in APIC, all the irq_chips support NMI delivery. However only one
> > of them will generate the NMI interrupt message, the rest (e.g., the local
> > APIC) will only relay it to the CPU.
> > 
> > So yes, I agree that the whole hierarchy should support NMI delivery, but
> > the chip generating the NMI is not necessarily the root chip.
> > 
> > One question that I have is that whether the new flag IRQCHIP_SUPPORTS_NMI
> > should be added to irq_chips that only relay NMIs or only to those from
> > which an NMI can be requested.
> 
> If we need to distinguish between the two, then we need two flags. One
> that indicates the generation capability, and one that indicates the
> forwarding capability.

There is absolutely no reason to expose this on x86, really.

Why?

Because NMI is an utter trainwreck on x86. It's a single entry point
without the ability of differentiation from which source the NMI
originated. So mapping it to anything generic is just not going to work.

It has absolutely nothing to do with the normal way of vector based
interrupt operation and I don't see at all how adding this just because
would improve anything on x86. In fact it would create more problems than
it solves.

Thanks,

	tglx