linux-kernel - Re: [PATCH][GIT PULL][v3.3] x86: Test saved %rip in NMI to determine nested NMI

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: <1329663451.25686.21.camel@gandalf.stny.rr.com>
Date:	Sun, 19 Feb 2012 09:57:31 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH][GIT PULL][v3.3] x86: Test saved %rip in NMI to
 determine nested NMI

On Sun, 2012-02-19 at 13:56 +0100, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > Ingo,
> > 
> > I found that it is possible for userspace to prevent an NMI 
> > from triggering while it is running by setting its stack 
> > pointer to that of the NMI stack. This tricks the NMI nested 
> > algorithm in thinking that the NMI is nested. The easy 
> > solution to this is to test the %rip to make sure that the NMI 
> > happened in kernel mode before testing for nesting.
> 
> Ouch...

Note, it does not seem to cause any destruction, but screw up profiling.
It doesn't change how timer interrupts, or any other interrupts work.
I'm not sure what problems this can cause on a security level. But it
needs to be fixed regardless.

> 
> > I've tested a program that exhibits the missing NMIs and this 
> > patch corrects that behavior.
> 
> Does it need a -stable tag?

The nesting code was introduced in 3.3 so this does not affect any major
released version of Linux.

> Does this do the right thing for the vDSO as well? It is in 
> negative addresses:
> 
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
> 

Hmm, I thought about this as well, Can that code run with a bad stack?
It would require a process to call this code using the NMI stack
pointer, and things like push and pop would cause the code to crash
immediately with a SEGFAULT.

I could add more checks in the nested NMI path, as that is the slow path
because nested NMIs are extremely rare.

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