linux-kernel - Re: [tip:x86/irq] x86: Always use irq stacks

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: <1279894516.3319.44.camel@gandalf.stny.rr.com>
Date:	Fri, 23 Jul 2010 10:15:16 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Christoph Hellwig <hch@....de>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/irq] x86: Always use irq stacks

On Wed, 2010-07-14 at 17:47 +0200, Christoph Hellwig wrote:

> > So you're saying, that the problem appears when
> > CONFIG_FUNCTION_GRAPH_TRACER is enabled w/o being used and that it
> > exists prior to your patches with irq stacks and 8k stack size, but
> > works with 4k stacks. That's definitely more than odd.
> 
> No, the problem does not show up with 8k stack size without irqstacks,
> and does not show up with 4k stacks with irq stacks, but does show up
> with 8k stacks with irqstacks as long as CONFIG_FUNCTION_GRAPH_TRACER is
> enabled. Just disabling it in Ingo's example config makes it work,
> and enabling it in my usual test configs makes the boot fail with
> similar messages to the one Ingo sees.

Examining the difference between 32bit and 64bit (where it only triggers
for 32bit) I found this:

In arch/x86/kernel/dumpstack_64.c:

        tinfo = task_thread_info(task);
[...]
                       bp = ops->walk_stack(tinfo, stack, bp, ops,
                                             data, estack_end, &graph);


Note: tinfo here that is passed to walk_stack() is the actual thread
info structure for the task.

In arch/x86/kernel/dumpstack_32.c:

                context = (struct thread_info *)
                        ((unsigned long)stack & (~(THREAD_SIZE - 1)));
                bp = ops->walk_stack(context, stack, bp, ops, data, NULL, &graph);

Note: here, context (which ends up being tinfo) is just a bitmasking of
the current stack. If the stack is the irqstack, then what is passed to
walk_stack() is not the actual thread info structure.

Note, if THREAD_SIZE is 8k and irqstacks are 4K then context is totally
wrong here.

Now for the reason that function graph noticed this:

static const struct stacktrace_ops print_trace_ops = {
        .warning                = print_trace_warning,
        .warning_symbol         = print_trace_warning_symbol,
        .stack                  = print_trace_stack,
        .address                = print_trace_address,
        .walk_stack             = print_context_stack,
};

Where walk_stack is print_context_stack:

tinfo is pretty much ignored in print_context_stack, but when function
graph is enabled we have:

                print_ftrace_graph_addr(addr, data, ops, tinfo, graph);

Which actually plays with the tinfo structure. If tinfo is corrupted
here, then we get the bug.

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