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 11:40:55 +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 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.

There is no way to make this work on x86 unless they fundamentally change
the low level exception mechanics. Not going to happen anytime soon. And if
it ever happens then they better implement it in a way which is usable by
software sanely.

Thanks,

	tglx