linux-kernel - Re: [PATCH RFC] NMI Re-introduce un[set]_nmi

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, 4 Sep 2008 17:18:32 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Prarit Bhargava <prarit@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, arozansk@...hat.com,
	dzickus@...hat.com, Thomas.Mingarelli@...com, ak@...ux.intel.com,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: [PATCH RFC] NMI Re-introduce un[set]_nmi_callback


* H. Peter Anvin <hpa@...or.com> wrote:

> Ingo Molnar wrote:
>>
>> i'd much rather attack this general problem from this angle:
>>
>>   static inline unsigned char get_nmi_reason(void)
>>   {
>>           return inb(0x61);
>>   }
>>
>> that port 61H read is both arcane (on modern chipsets) and broken on  
>> multiple levels. It's racy and SMP unsafe to begin with, if there's any 
>> mixture of intentional cross-CPU or CPU self-generated NMIs mixed with  
>> chipset generated NMIs.
>>
>> One possible approach would be to get rid of it, and to perhaps 
>> register a low-priority die notifier on systems where we know port 61  
>> reads+writes to be safe and desired. Modern systems will emit MCEs in  
>> most cases anyway, not NMIs.
>>
>
> I believe we should still do it, but as the lowest priority "nothing 
> else claimed this".  It reflects a system error and not all systems 
> will generate #MC instead of NMI for all system errors.
>
> Pretty much what you're saying above.

ok. One potential additional concern i can think of is multi-source 
NMIs: NMIs, when generated by some sort of hardware are edge triggered 
most of the time, so if in the notifier chain a notifier decides "this 
was for me, return now", we will lose an event.

So i think we should iterate through all notifier entries and call them 
(even if all of them indicate that they handled it), and determine 
whether at least one notifier handled something. If nothing handled the 
NMI _then_ do the port 61H logic as a final fall-back thing.

	Ingo
--
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/