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 PHC | |
Open Source and information security mailing list archives
| ||
|
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/
Powered by blists - more mailing lists