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: <1323442828.1937.17.camel@frodo>
Date:	Fri, 09 Dec 2011 10:00:28 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Jason Baron <jbaron@...hat.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 Fri, 2011-12-09 at 10:22 +0100, Peter Zijlstra wrote:

> Its was definitely tongue in cheek, also I did say this'll be a massive
> pain with paravirt since I doubt paravirt calls are NMI safe. 

But does paravirt simulate NMIs? Does a guest ever take an NMI? I can
enable paravirt to see if it breaks.

> 
> But yeah, it might all be slightly less painful than trying to teach the
> INT3 handler about this recursion.

That's my goal. Yes, I agree this is all just an ugly hack, but I'm
trying hard to keep the ugly hack contained in the NMI handling. Once
you start letting this hack spread, it will grow like a virus, and
resistance will be futile. And we will end up with nasty dependencies
that will become a horror show to maintain.

Right now, I've quarantined the NMI code, and I'm keeping the infection
at bay. The NMI code will grow warts and nasty appendages, but the NMI
code was ugly to begin with, and maybe these mutations might even make
it prettier. That's the nature of NMI. It's an ugly beast in all its
incarnations.

This is why I like my patches. It contains the damage to only the NMI
code. If something breaks from this code, it will be easy to find it. If
anything, a bisect should show exactly what caused change caused the
problem. But if we add hacks in other places, it will be much more
difficult to figure out.

> 
> This all started with wanting to do pagefaults from NMI context, those
> too will have this recursion, although for faults we'll end up in the
> double fault handler, which seems to allow a slightly saner way out.

It didn't start with the pagefaults. That discussion only brought the
issue to LKML. This has been a pain in our side or breakpoints from day
one.

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