This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: dwarf unwinder branch
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Martin Hunt <hunt at redhat dot com>
- Cc: systemtap at sourceware dot org
- Date: Tue, 01 Apr 2008 23:04:48 -0400
- Subject: Re: dwarf unwinder branch
- References: <1206979860.22650.28.camel@dragon>
hunt wrote:
> I have checked in some major work on a new branch. Please take a look
> if you are interested.
Thanks.
> * new dwarf unwinder. Stack traces are now far more accurate than
> with the previous best-guess unwinder.
That was a nice bonus, though the main reason has been that we need
this for doing any sort of user-space backtracing.
Considering the rather bulky unwind_frame_info struct copy that is now
allocated on the stack during unwinding, and all the new unwind data
checking/walking code, have you looked at kernel stack overflow
issues?
> * staprun no longer serves any symbols. kernel symbols are compiled
> in by stap.
This seems to have been done by re-enabling the ancient
/proc/kallsyms-based hack. This is not adequate, as it ignores
cross-compilation needs (different kernel version, maybe architecture,
and possibly relocation changes). For the last of these issues,
symbols need to be passed through the _stp_module_relocate mechanism.
> The currently loaded modules, their locations and symbols are read
> directly from the kernel.
To what extent is this information protected from corruption by
subsequent or concurrent module load/unload operations?
> * stapio now can send unwind data when requested. stapio is running as
> a normal user and perhaps not secure, but I think the best a hacker
> could do would be to fool systemtap into making inaccurate backtraces.
> [...] When a module is loaded, my code gets the unwind data and
> does a lot of checking on it. Any problems and all the data is
> freed and not used.
I suspect this part will not become trustworthy enough to rely on, as
it gives an unprivileged user the capability to send a big complicated
data blob to the kernel. Even if the checking is perfect, something
as mundane as a DoS could still occur, just by flooding your code with
unwind-data-verification requests.
> For i386 and arm only, if kernel is built with CONFIG_STACK_POINTER,
> frames are used for backtracing instead of the new code. [...]
It would appear as if the potentially infinite loop (while loop in the
__stp_stack_print code) can in fact go infinite if the stack is
corrupted just the right way.
- FChE