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: User Stack Trace


On Tue, Apr 17, 2007 at 03:39:58PM -0400, Frank Ch. Eigler wrote:
> grundym@us.ibm.com (grundy) writes:
> 
> > [...]
> >         struct frame_head {
> >                 struct frame_head * ebp;
> >                 unsigned long ret;
> >         } __attribute__((packed)) stack_frame[2], *head;
> > [...]
> >         head = (struct frame_head *)nregs->ebp;
> >         if (user_mode_vm(nregs)) {
> > [...]
> >                         _stp_copy_from_user ((char *)stack_frame, 
> >                                 (const char __user *) head->ebp,
> >                                 sizeof(stack_frame));
> >                         head = stack_frame;
> > [...]
> 
> To what extent does this work for user code compiled without frame
> pointers?  
Since it follows back through the return addresses, I don't think it
matters if it's compiled with or without. That could be a clueless
assumption on my part. I'll have to write some specific test cases to
verify this. 

> Or containing corrupt/malicious stack data?
Now this is interesting. One would have to corrupt return address prior
to the syscall we're tracing. They would have to know exactly what we're
tracing (possible) because once that call started to return it would
turn left into the lake (if we weren't probing that call). I don't think
there is an execution vulnerability, we just record the address. There
is a chance of someone setting up a loop. Fake the second return address
to point at the first return address which points at the second. 

In the jprobe code I based this on, I set an arbitrary depth limit of
20. Once you hit that bang out. So something like set a maximum depth
variable to 20 or 30 and add this to the loop:
while (--depth && head->ebp);

I should also note that we had some issues on x86_64 with nregs going
away if you ctrl+c out of a running program (test was cancelling a
kernel build) using the kread macro fixed that up. 

I'll put up that modified version later when I post the version with vma
name resolution. 

Thanks
Mike


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