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: <20120312195842.GF17288@redhat.com>
Date:	Mon, 12 Mar 2012 15:58:42 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, "H. Peter Anvin" <hpa@...or.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
Subject: Re: [PATCH 1/2] boot: ignore early NMIs

On Mon, Mar 12, 2012 at 12:02:06PM -0700, Eric W. Biederman wrote:
[..]
> 
> > I personally think that disabling LAPIC is reasonably practical solution
> > to the problem until and unless somebody shows that it deadlocks
> > easily.
> 
> Disabling NMI generation in the LAPIC is fine, and for the short term
> I don't even have a problem with disabling the entire LAPIC as all of
> our platforms seem to have code for completely reprogramming it.
> 
> At the same time there have been cases like the i8259 routed through
> the ExtInt pin of the lapci that we haven't been given programming
> information about and that if we want to work we should avoid touching.
> 
> Furthermore we have two reported cases of people experiencing real NMIs
> on the kdump path.  So we have to assume the presence of the CMOS nmi
> disable as well if we are going to unequivocally disable NMIs.

So Don reported NMI problem only after he stopped disable_local_APIC().
His NMIs were being generated from Local APIC. The only question left
is what kind of NMIs Fernando was seeing.

> 
> Given the variety of x86 hardware today and the growing variety of x86
> hardware tomorrow we are going to be fixing this until we can actually
> handle the NMIs.  Hardware designers are unfortunately creative enough
> that we aren't going to think of everything.  Given that it is has taken
> us almost a decade to realize that there actually is a real world
> problem  I'm not too keen on a solution that is just good enough to
> fix a small problem.

Problem might be small but it has been noticed and fix is simple. That's
a different thing that it might not cover all other cases you mention.

And to begin with problem was with ioapic lock and we are blocking the
that fix because we want NMI handling to be cleaned up too.

So atleast Don's ioapic locking fix should be allowed to go in and then
debate can continue that what's the best fix to handle NMIs from all
sort of situations.

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