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: <1323870059.23971.23.camel@gandalf.stny.rr.com>
Date:	Wed, 14 Dec 2011 08:40:59 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [RFC][PATCH 5/5 v2] x86: Allow NMIs to hit breakpoints in i386

On Wed, 2011-12-14 at 08:30 -0500, Mathieu Desnoyers wrote:

> Just to make sure I understand: if an NMI nests over do_nmi between
> nmi_postprocess() and the following iret (in which case the CPU is in
> state NMI_NOT_RUNNING), we will end up with two NMI handlers nested on
> the stack, right ? Given that there is no upper-bound on the nesting
> level of this situation (although nesting like this more than once is
> extremely unlikely), is this side-effect something we should care about
> in terms of stack space usage ?

At that point, there's very little on the stack to begin with. Just the
one irq frame, and saved regs, plus the stack frame of this function. If
we are hitting that many NMIs to cause a stack overflow, then I believe
there's more issues than the overflow itself. Say, a livelock of NMIs?

>  Also, is the stack dump OOPS handler
> aware of this stack layout that was until now impossible ?

Since NMIs on i386 doesn't change the stack when interrupting the
kernel, the OOPs handler never was aware of the NMI stack layout.

-- Steve



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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ