linux-kernel - Re: [V5][PATCH 4/6] x86, nmi: add in logic to handle multiple events and unknown NMIs

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: <20110921160409.GE6063@erda.amd.com>
Date:	Wed, 21 Sep 2011 18:04:09 +0200
From:	Robert Richter <robert.richter@....com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Don Zickus <dzickus@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	Andi Kleen <andi@...stfloor.org>,
	"ying.huang@...el.com" <ying.huang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"paulmck@...ux.vnet.ibm.com" <paulmck@...ux.vnet.ibm.com>,
	"avi@...hat.com" <avi@...hat.com>,
	"jeremy@...p.org" <jeremy@...p.org>
Subject: Re: [V5][PATCH 4/6] x86, nmi:  add in logic to handle multiple
 events and unknown NMIs

On 21.09.11 11:33:52, Peter Zijlstra wrote:
> On Wed, 2011-09-21 at 17:18 +0200, Robert Richter wrote:
> > 1. The cpu executes some microcode or SMM code.
> > 2. HW triggers the first NMI, an NMI is pending.
> > 3. HW triggers a second NMI, the NMI is still pending.
> > 4. The cpu finished microcode or SMM code.
> > 5. NMI handler is called, no NMI pending anymore.
> > 6. Return from NMI handler. 
> 
> Even without SMM, all you need is two different NMI users to trigger
> while an NMI is in flight.
> 
> Wouldn't be entirely impossible to trigger if you have
> non-fatal-MCE/hardware-NMI-switch/PMI all active.

No, I am trying to explain this...

If hw triggers more than one nmi *before* the nmi handler is entered
(no matter what the source is), then there will be no back-to-back
nmi. NMIs are edge triggered and there is only one pending signal (AMD
cpus). The signal is cleared when entering the handler. If the cpu
executes microcode or smm code and delays execution of the nmi
handler, then there is no second call of the handler even if there are
2 sources for it.

-Robert


-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/