linux-kernel - Re: [PATCH -v3 5/6] x86, NMI, treat unknown NMI as hardware error

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: <20101020141558.GB19090@redhat.com>
Date:	Wed, 20 Oct 2010 10:15:58 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Huang Ying <ying.huang@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Robert Richter <robert.richter@....com>, peterz@...radead.org
Subject: Re: [PATCH -v3 5/6] x86, NMI, treat unknown NMI as hardware error

On Wed, Oct 20, 2010 at 02:12:37PM +0800, Huang Ying wrote:
> Hi, Don,
> 
> On Tue, 2010-10-12 at 05:20 +0800, Don Zickus wrote:
> > > @@ -366,6 +368,15 @@ unknown_nmi_error(unsigned char reason,
> > >  	if (notify_die(DIE_NMIUNKNOWN, "nmi", regs, reason, 2, SIGINT) ==
> > >  			NOTIFY_STOP)
> > >  		return;
> > > +	/*
> > > +	 * On some platforms, hardware errors may be notified via
> > > +	 * unknown NMI
> > > +	 */
> > > +	if (unknown_nmi_as_hwerr)
> > > +		panic(
> > > +		"NMI for hardware error without error record: Not continuing\n"
> > > +		"Please check BIOS/BMC log for further information.");
> > > +
> > >  #ifdef CONFIG_MCA
> > >  	/*
> > >  	 * Might actually be able to figure out what the guilty party
> > 
> > The only quirk I have left is the above piece, which is basically a
> > philosophy difference with Robert and myself.  Where we believe it should
> > be on the die_chain and Andi and yourself would like to see it explicitly
> > called out.
> 
> After some more thought, I found this is different from DIE_NMI and
> DIE_NMI_IPI case. I think the code added is for general unknown NMI
> processing instead of a device driver. What we do is not to add special
> processing for some devices, but treat unknown NMI as hardware error
> notification in general and use a white list to deal with broken
> hardware and stone age machine. Do you agree?
> 
> If so, it should not be turned into a notifier block unless you want to
> turn all general unknown NMI processing code into a notifier block.

Well, yes I actually do, mainly to keep the code simpler.  But also, after
having a conversation with someone yesterday, realized that unknown NMIs
are dealt with on a platform level and not a chipset level.

The reason I say that is some companies, like HP, have a special driver
hpwdt that they want to run in the case of an unknown NMI.  They don't
care about HEST or the other stuff, they want their BIOS call to take care
of it.  So now that hack has to be put into notifier somewhere.

I can only imagine Dell trying to do something similar as a value add.

To me it just makes sense to setup all the HEST stuff as default notifier
blocks and then have platform specific drivers register on top of them
(using the priority scheme).  This to me gives everyone flexibility on how
to handle the unknown NMIs.

Thoughts?

Cheers,
Don
--
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/