Copying kernel stack in a generic way

Copying kernel stack in a generic way

Elazar Leibovich elazarl at gmail.com
Wed Jan 7 11:50:01 IST 2015


For future reference.

I examined what perf does when sampling the stack, (e.g. "-g").

0. Indeed, it does not support callchain when sampling guest KVM OS.
Probably because it's not trivial to find out safely where the stack starts

http://lxr.free-electrons.com/source/arch/x86/kernel/cpu/perf_event.c#L1965
void
perf_callchain_kernel(struct perf_callchain_entry *entry, struct pt_regs
*regs)
{
if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
* /* TODO: We don't support guest os callchain now */*
return;
}
perf_callchain_store(entry, regs->ip);
dump_trace(NULL, regs, NULL, 0, &backtrace_ops, entry);
}

1. It assumes the kernel is compiled with a frame pointer, and would walk
through frame pointer until it reaches an invalid one. Presumably there's
an invalid frame pointer at the top of the stack.
(stack walking func is print_context_stack_bp):

http://lxr.free-electrons.com/source/arch/x86/kernel/dumpstack.c#L122

while (valid_stack_ptr(tinfo, ret_addr, sizeof(*ret_addr), end)) {
unsigned long addr = *ret_addr;
if (!__kernel_text_address(addr))
break;
ops->address(data, addr, 1);
frame = frame->next_frame;
ret_addr = &frame->return_address;
print_ftrace_graph_addr(addr, data, ops, tinfo, graph);
}

On Sun Dec 21 2014 at 9:28:01 AM Muli Ben-Yehuda <mulix at mulix.org> wrote:

> On Fri, Dec 19, 2014 at 02:19:07PM +0000, Elazar Leibovich wrote:
>
> > I know where the stack ends, but how can I know where it begins?
>
> What assumptions can you make? Can you run kernel code in the VM
> (e.g., by cloning and restarting it)? Can you assume it's running
> Linux and/or Windows? Can you assume the kernel was compiled with
> frame pointers? Or is it a completely black box VM and you can't make
> any assumptions about what's running inside?
>
> > I can check the memory mapping, and assume nothing would take the
> > virtual address before the start of the kernel's stack, but I don't
> > know if I can count on it for most mainstream OSes.
>
> That's a pretty good heuristic but see questions above.
>
> By the way, some OS's have separate interrupt stacks, so you may be on
> an interrupt stack or on a regular stack.
>
> > Maybe there's a known method I'm missing, I'll be happy for any
> > comments.
>
> Cheers,
> Muli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20150107/6c539b2e/attachment-0001.html>


More information about the Linux-il mailing list