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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1808030952400.1841@nanos.tec.linutronix.de>
Date:   Fri, 3 Aug 2018 09:59:38 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
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, 2 Aug 2018, Ricardo Neri wrote:
> On Thu, Aug 02, 2018 at 11:40:55AM +0200, Thomas Gleixner wrote:
> > 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.

This assumption is fundamentally wrong. It wont't work unless Intel decides
to sanitize the whole exception mechanism. We can discuss that once this
happens, but I assume that this will be after my retirement.

> 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.

That HPET thing is a dead horse and won't become more alive by adding magic
to the irq core code.

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

There is nothing to reserve. Code which needs to deal with NMIs is better
written safe and sound and no, we won't expose NMIs to random device driver
code either.

Thanks,

	tglx