linux-kernel - Re: [PATCH] x86: sysctl to allow panic on IOCK NMI 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: <20090702075305.GC19187@elte.hu>
Date:	Thu, 2 Jul 2009 09:53:05 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Borislav Petkov <borislav.petkov@....com>
Cc:	Greg KH <gregkh@...e.de>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Kurt Garloff <garloff@...e.de>, linux-kernel@...r.kernel.org,
	Yinghai Lu <yinghai@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] x86: sysctl to allow panic on IOCK NMI error


* Maciej W. Rozycki <macro@...ux-mips.org> wrote:

> On Wed, 1 Jul 2009, Ingo Molnar wrote:
> 
> > >  ENOTIME, sorry.  Next year perhaps.  Or a homework project 
> > > for one of the newbies. ;)
> > 
> > You know that this project would kill a newbie, right? :)
> 
>  Well, that's just a fast track to become a veteran, isn't it? ;)

No, that's just a fast track to quickly make it into the list of our 
Fallen Heroes :-/ The fast track to become a kernel veteran is to, 
if possible, not challenge a tank with a hand-grenade. But i 
digress.

> > We have no real southbridge drivers on x86 - but we should 
> > certainly add some. Also, walking the PCI device tree from NMI 
> > context is tricky as the lists there are not NMI safe - we could 
> > crash if we happen to get a #IOCK while loading/unloading 
> > drivers (which is rare but could happen).
> 
> That shouldn't be a problem if we were about to panic().  For a 
> more sophisticated attempt of recovery -- yes, that would have to 
> be addressed.

We are only panic-ing if the sysctl is set. The diagnostics would be 
useful anyway. The proper approach would be to defer it a bit in the 
non-panic case an read it out from some friendlier context - such as 
the EDAC core.

	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/