linux-kernel - Re: [PATCH 1/2] boot: ignore early 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: <4F5D943C.5020403@oss.ntt.co.jp>
Date:	Mon, 12 Mar 2012 15:14:20 +0900
From:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Don Zickus <dzickus@...hat.com>,
	linux-tip-commits@...r.kernel.org, torvalds@...ux-foundation.org,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	mingo@...hat.com, tglx@...utronix.de, mingo@...e.hu,
	Yinghai Lu <yinghai@...nel.org>, akpm@...ux-foundation.org,
	vgoyal@...hat.com
Subject: Re: [PATCH 1/2] boot: ignore early NMIs

On 03/12/2012 02:49 PM, H. Peter Anvin wrote:

> On 03/11/2012 10:43 PM, Fernando Luis Vázquez Cao wrote:
>> To tackle this issue we can either stop the hardlockup detector
>> or disable the LAPIC (the NMIs needed by x86's hardlockup detector
>> are generated using performance counters in the LAPIC), leaving
>> the I/O APICs untouched. The second is simpler and I think it
>> is the approach Don took to fix this issue in RHEL kernels.
>>
>> Unfortunately, this is not enough, we are still exposed to external
>> NMIs not routed through the LAPIC. In other words, we have to make
>> sure that we always have and IDT that is able to handle NMIs without
>> seemingly random reboots and lockups. To achieve this goal we need
>> to fix machine_kexec() and the early IDT handlers. The current patch
>> set takes care of the latter.
> The only source of NMIs other than the LAPIC should be the system error
> which can be disabled through the RTC port, so I think your second
> paragraph here is way more mechanism than you need for very little gain.

The thing is that we want to avoid playing with hardware in the kdump
reboot patch when we can avoid it, the premise being that it cannot
be accessed without risking a lockup or worse (as the deadlock accessing
the I/O APIC showed). The kernel is crashing after all. What is more,
I forgot to mention that the long term goal is to leave the LAPIC
untouched too (we really want to keep the number of things we do in the
context of the crashing kernel to the bare minimum), so we would still
need to fix the early IDT.

My patch set just installs a special handler for the NMI case so I think
it is pretty simple and self contained.

Another reason to apply these patches is to be consistent with the rest
of the kernel. Spurious NMIs that would have been ignored after installing
the final IDT would cause the system to halt if they happen
to arrive while the early IDT is in place.

- Fernando

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