linux-kernel - Re: NMI vs #PF clash

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: <1337695780.13348.41.camel@gandalf.stny.rr.com>
Date:	Tue, 22 May 2012 10:09:40 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Avi Kivity <avi@...hat.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Paul Turner <pjt@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: NMI vs #PF clash

On Tue, 2012-05-22 at 16:45 +0300, Avi Kivity wrote:

> I thought the whole thing was started by someone adding a
> vmalloc_sync_all() to prevent this scenario, and Linus wanting to
> fix NMI instead.  But maybe I'm confusing two threads.

No, you are rightfully confused.

That was the case that started the thread and created the eventual code
that we have. But Mathieu Desnoyers brought this up not to just solve
the page fault issue for perf, but also to handle page faults for his
own ring buffer and as a nice side effect, fixing breakpoints, which is
critical to be able to modify text without the use of stop machine.

But the answer was to modify perf to not need to use vmalloc'd data from
NMI context. Or at least never do it where a page fault could happen.

The motivation for me to allow faults in NMI context was for
breakpoints, as it was required to remove stop machine from the function
tracer.

> 
> > Now if we want to handle page faults from NMI context, we could do some
> > tricks to have the NMI detect that it interrupted a page fault before it
> > read the cr2 and in that case, save off the cr2 register, and restore it
> > before returning.
> > 
> > Or we could just have the NMI always restore the cr2 register.
> 
> IMO that's best.

OK, I can whip up a patch, but I wont push that in till 3.6.

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