This is the mail archive of the systemtap@sources.redhat.com 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: [Fwd: Re: [PATCH] Return probe]


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>


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