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]

Message-ID: <20180803030947.GA12916@voyager>
Date:   Thu, 2 Aug 2018 20:09:47 -0700
From:   Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Marc Zyngier <marc.zyngier@....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, Aug 02, 2018 at 11:40:55AM +0200, Thomas Gleixner wrote:
> On Thu, 2 Aug 2018, Marc Zyngier wrote:
> > On Thu, 02 Aug 2018 07:55:49 +0100,
> > Thomas Gleixner <tglx@...utronix.de> wrote:
> > > 
> > > On Thu, 2 Aug 2018, Marc Zyngier wrote:
> > > > 
> > > > 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.
> > 
> > Fair enough. Does it mean Julien can completely ignore the x86
> > requirements for this and focus on something that fit the need of
> > architectures where (pseudo-)NMIs can be managed similarly to normal
> > interrupts (arm, arm64, sparc...)?
> 
> Yes, focussing on "sane" architectures (by some definition of sane) where
> the NMI mode is just changing the delivery restrictions allows to still
> differentiate from which source the NMI originates.

Let me assume that one can find a way to reliably identify the source of an
NMI in x86. If we cannot use the proposed request_nmi() as it does not fit
x86, is it acceptable to bypass the existing irq framework and directly
program the delivery mode as NMI in the relevant hardware (e.g., a register
holding the MSI data)? For instance, in my initial attempt to have the HPET
timer to generate NMIs [1]. I could directly write to the FSB Interrupt
Route Register. In my view, it makes sense because, as you say, in x86 NMIs
are handled separately from the normal vector based interrupts.

I guess this would also imply reserving the relevant hardware so that it
is not used when calling request_irq().

Thanks and BR,
Ricardo

[1]. https://lore.kernel.org/patchwork/cover/953394/