Re: dwarf unwinder branch

[Martin Hunt <hunt at redhat dot com>]

On Tue, 2008-04-01 at 23:04 -0400, Frank Ch. Eigler wrote:

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

I have not seen any issues, no. But you are right that the stack
allocation (188 bytes) should probably be changed. But we can't just
make it static because there will be multiple traces happening
concurrently. So it has to be changed to percpu.  Which means it has to
be allocated when the module is loaded and freed on exit. I've made a
note to do this.

> > * 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.  

No, it is an entirely new hack! But it still uses /proc/kallsyms, just
not in the old slow, ugly way.  Next step is to replace this with
something that gets the symbols out of libdw, which I don't have working
yet.

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

Yes, we will get there.  

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

While reading from the kernel, we hold module_mutex, which prevents any
module loads/unloads.  Subsequent module loads will trigger the runtime
to update it's module list, symbols, and unwind data.  And all those
internal data structures are protected with rwlocks. 

> > * 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.

As this would only happen once per module load, it is hard to see how
the load would be significant enough to cause a Dos.  The whole module
loading process is a much bigger load on the system.  If you want to
kill the system, just load a bunch of large systemtap modules, no unwind
data needed.

And if you aren't trusting unwind data sent from userspace, how do you
plan to handle debugging of user applications?  Where will their unwind
data come from?

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

Yes, I was not as paranoid about bad stack data when using stack frames.
I'll put an extra check there so systemtap can print a warning. Of
course the system will then lockup when normal execution hits that place
in the stack, but at least no one will blame systemtap.

Martin