linux-kernel - Re: [RFC][PATCH 3/3] x86: Add workaround to NMI iret woes

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: <1323442162.1937.8.camel@frodo>
Date:	Fri, 09 Dec 2011 09:49:22 -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>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jason Baron <jbaron@...hat.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [RFC][PATCH 3/3] x86: Add workaround to NMI iret woes

On Fri, 2011-12-09 at 08:02 -0500, Mathieu Desnoyers wrote:
> * Mathieu Desnoyers (mathieu.desnoyers@...icios.com) wrote:

> after a quick IRC discussion with Peter Zijlstra, one thing seems to be
> missing here to handle the INT3->NMI->INT3 issue: this could be achieved
> by splitting the DEBUG stack in 2 sub-stacks, and letting the int3
> handler keep track of its nesting within its own stack with an extra
> "int3_nest_count". AFAIU, supporting 2 nested int3 should be enough.

Here's the problem. When you take an int3, the hardware loads stuff onto
the stack for you. That's the SS, RSP, FLAGS, CS, RIP. If the NMI comes
in while we are processing a breakpoint, and the NMI hits an int3 too,
then the hardware will load the current SS, RSP, FLAGS, CS and RIP onto
the stack at the exact same place as the breakpoint processing that was
interrupted had it's interrupt frame. IOW, it just corrupted the stack.

To prevent this in the NMI code, I did ugly things like making copies of
the interrupt frame to keep a nested NMI from corrupting the first NMI.
Not only do I not want to do this ugly hack for debug exception, you
*can't* do it. It wont work!

The reason the NMI works is because while we are copying the stack
frame, NMIs are disabled because we are currently in an NMI.

But a normal int3, as it tries to do the copy and an NMI triggers, if
you don't update the IDT, any int3 that the NMI hits will corrupt the
previous int3 processing's stack. The hardware does it, there's nothing
a "split stack" will do to fix that.

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