linux-kernel - Re: [PATCH 4/5] x86: Allow nesting of the debug stack IDT setting

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: <1338500240.13348.453.camel@gandalf.stny.rr.com>
Date:	Thu, 31 May 2012 17:37:20 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Dave Jones <davej@...hat.com>, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 4/5] x86: Allow nesting of the debug stack IDT setting

On Thu, 2012-05-31 at 14:09 -0700, H. Peter Anvin wrote:

> No, I'm asking what environments (alternate stacks) are permitted where.
>  That is the important information.

I believe that the IST stack switch is just a convenient way to allow
separate stacks for separate events instead of trying to handle all
events on a single stack, and risk stack overflow.

Thus, the debug/int3 and NMI events use a separate stack to not stress
the current stack that is not expected to switch. The external interrupt
stacks are switched on entry of the interrupt and stays on that stack
and until its finished. There's a check to see if it is already on the
stack before it does the switch so that it doesn't have the HW switch
issues that NMI and int3 has.

Thus, if we say we must stay on either the NMI stack or the DEBUG stack,
then this is what happens. Well, almost.

For NMIs, if it preempted something on the debug stack, it will always
stay on the NMI stack and never switch. A check is made for both debug
stacks at once:

int is_debug_stack(unsigned long addr)
{
	return __get_cpu_var(debug_stack_usage) ||
		(addr <= __get_cpu_var(debug_stack_addr) &&
		 addr > (__get_cpu_var(debug_stack_addr) - DEBUG_STKSZ));
}

Where:

#define DEBUG_STACK_ORDER (EXCEPTION_STACK_ORDER + 1)
#define DEBUG_STKSZ (PAGE_SIZE << DEBUG_STACK_ORDER)

But if the NMI did not preempt the DEBUG stack, and it hits a breakpoint
it will switch to the debug stack. And it is possible to make another
switch if the debug code were to somehow.

Thus the transactions are something like this:

NORMAL_STACK (either kernel/user/irq) -> DEBUG1 -> DEBUG2

NORMAL_STACK -> DEBUG1 -> NMI

NORMAL_STACK -> DEBUG1 -> DEBUG2 -> NMI

NORMAL_STACK -> NMI -> DEBUG1 -> DEBUG2

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