This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dwarf unwinder branch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]