This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: [Fwd: Re: [PATCH] Return probe]
- From: Prasanna S Panchamukhi <prasanna at in dot ibm dot com>
- To: Jim Keniston <jkenisto at us dot ibm dot com>, Richard J Moore <richardj_moore at uk dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Wed, 20 Apr 2005 20:32:53 +0530
- Subject: Re: [Fwd: Re: [PATCH] Return probe]
- Reply-to: prasanna at in dot ibm dot com
Hi Jim,
>>
>> 1) What happens if the return address is modified by the called program
>> (legitimately or otherwise)?
>Assuming it's modified after the entry probe has been hit and processed,
>the modified return address will be used. The trampoline won't be hit,
>the return handler won't be run, and we'll leak a kretprobe_instance
>object. If we eventually leak all that kretprobe's kretprobe_instance
>objects, the return handler for that kretprobe won't run any more, and
>the kretprobe's nmissed counter will grow accordingly. Nothing else will
>be affected.
Return address corruption stored on the stack (and consequent leak) can
be prevented by placing a watchpoint (hardware breakpoint using debug
registers) on the stack where the return address is stored. There are
other issues such as watchpoint depletion, multi-level function returns,
handling of recussion for which Richard's has some solution.
This ofcourse applies to only x86-like architectures.
One more advantage of using this approach is that there is no overhead
of handling kretprobe instances leak by calling kprobe_flush_task()
for every do_exit and do_execv.
Thanks
Prasanna
--
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
<prasanna@in.ibm.com>