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]

Date:	Fri, 9 Dec 2011 11:49:17 -0500
From:	Jason Baron <jbaron@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
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>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.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 Thu, Dec 08, 2011 at 09:43:36PM -0500, Steven Rostedt wrote:
> On Thu, 2011-12-08 at 14:36 -0500, Steven Rostedt wrote:
> 
> > I'm not sure how to handle this case. We could do something similar in
> > the break point code to handle the same thing. But this just seems
> > really ugly.
> > 
> > Anyone with any better ideas?
> 
> On IRC, Peter Zijlstra mentioned changing the IDT in NMI. I'm not sure
> if he was joking or not. But I decided to try it out. It seems to
> work :)
> 
> 
> What's nice is that this change is in the C code, which makes things
> much easier.
> 
> I check on nmi entry, if the nmi preempted code running with the debug
> stack. If it has, then I load a special "nmi_idt_table" that has a zero
> IST for the debug stack, which will make the debug interrupt in the NMI
> not change the stack pointer. Then on exit, it returns it to the old IDT
> table.
> 
> Just to see how bad this was, I made it make the change on every NMI. I
> didn't notice any difference, but I wasn't doing any real benchmark,
> except doing a perf top -c 1000.
> 
> But in practice, it should seldom hit, if ever. It only updates the IDT
> if it interrupted debug processing.
> 

Then, I'm wondering if the same technique can be used for the original
nmi->int3->nmi case. That is, switch the IDT when the int3 comes in, so
that the subsequent nmi will be handled on the debug stack. As you pointed out,
these nesting and thus the IDT switching would be rare in
practice. (I know you don't want to touch any code outside of nmi :))

Thanks,

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