[Bug runtime/12026] Revamp task_backtrace() to use same unwinder backtrace()

["mjw at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From mjw at redhat dot com  2010-09-27 21:49 -------
function task_backtrace:string (task:long) defined in context-unwind.stp is
different from all other backtrace related functions like [[s]print][u]backtrace().

task_backtrace uses the function _stp_stack_[sn]print_tsk defined in stack.c and
only works when STAPCONF_KERNEL_STACKTRACE is defined true. This is the
in-kernel backtrace fallback which only works when there are frame pointers. All
other unwind related tapset functions go through _stp_stack_print (also from
stack.c). This uses the dwarf unwinder when possible and falls back to an
architecture specific unwinder or the in-kernel backtrace support when available.

Ideally task_backtrace, _stp_stack_[sn]print_tsk, would go through
_stp_stack_print also, so that it would invoke the dwarf unwinder. Currently
_stp_stack_print only works for the current task (if no task/NULL is given a
kernel backtrace is generated). This is because it needs to get a current set of
registers to init the dwarf unwinder state.

The register set comes either from CONTEXT->regs, if CONTEXT->regflags marks it
as valid for the current kernel/user space context. Or through
task_pt_regs(current). In the later case it uses _stp_task_pt_regs_valid from
runtime/compatdefs.h to check whether the register set is valid.

_stp_task_pt_regs_valid uses a very crude heuristic. It assumes the given task
== current, and if so (because the current task must have hit a probe point) the
register set returned by task_pt_regs(current) is valid if it the architecture
is i386, otherwise it is not. (See the XXX in the function comments for some
hints on improving on this.)

The above heuristic cannot really be used when using arbitrary tasks, since they
may be in any state (since they have not just been hitting a probe point). So
they may be running in either user or kernel space, so the register set you get
from task_pt_regs might not be current/sane.

It might be possible to just try to use the results of task_pt_regs and make the
result invalid (so the dwarf unwinder will use as little of the register set as
possible, see arch_unw_init_frame_info sanitize), and just hope for the best.
But this might give inaccurate/invalid/wrong backtraces.

Note that even if the register set is setup correctly the dwarf unwinder still
needs the unwind frame data of the task to function (for user space).

BTW. Double check security impact of this. Inspection of backtraces of tasks
not-owned by the user running the script should be disallowed.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=12026

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.