linux-kernel - Re: [PATCH 10/19] x86/dumpstack: add get_stack

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: <20160726185637.u5vilk3k4v2ztlac@treble>
Date:	Tue, 26 Jul 2016 13:56:37 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Brian Gerst <brgerst@...il.com>,
	Kees Cook <keescook@...omium.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Byungchul Park <byungchul.park@....com>
Subject: Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Tue, Jul 26, 2016 at 01:51:27PM -0400, Steven Rostedt wrote:
> On Tue, 26 Jul 2016 11:26:42 -0500
> Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> 
> 
> > Ok, I think that makes sense to me now.  As I understand it, the
> > "outermost" RIP is the authoritative one, because it was written by the
> > original NMI.  Any nested NMIs will update the original and/or iret
> > RIPs, which will only ever point to NMI entry code, and so they should
> > be ignored.
> 
> Just to confirm:
> 
>   -- top-of-stack --
>   [ hardware written stack ] <- what the NMI hardware mechanism wrote
>   [ internal variables ] <- you don't need to know what this is
>   [ where to go next ] <- the stack to use to return on current NMI
>   [ original copy of hardware stack ] <- the stack of the first NMI
> 
> IIRC, the original version had the "where to go next" stack last, but
> to keep pt_regs in line with the stack, it made sense to have the
> original NMI stack at the bottom, just above pt_regs, like a real
> interrupt would.
> 
> > 
> > But I think there's a case where this wouldn't work:
> > 
> > task stack
> > NMI
> > IST
> > stack dump
> > 
> > If the IST interrupt hits before the NMI has a chance to update the
> > outermost regs, the authoritative RIP would be the original one written
> > by HW, right?
> 
> The only IST interrupt that would hit there is MCE and it would
> probably be a critical error. Do we really need to worry about such an
> unlikely scenario? The system is probably doomed anyway.

According to entry_64.S:

	/*
	 * We allow breakpoints in NMIs. If a breakpoint occurs, then
	 * the iretq it performs will take us out of NMI context.
	 * This means that we can have nested NMIs where the next
	 * NMI is using the top of the stack of the previous NMI.

So I think this means that when a debug exception returns to an NMI with
iret, further NMIs are no longer masked.

-- 
Josh