Re: [RFC] Multiple kprobes at an address redux (take3)

[Maneesh Soni <maneesh at in dot ibm dot com>]

On Tue, Apr 12, 2005 at 09:33:48AM -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> 
> On Tue, Apr 12, 2005 at 12:23:32PM +0530, Suparna Bhattacharya wrote:
> > [...]
> > > >Thanks to Suparna, I see there could be a problem in this which might 
> > > >occur due to this non-exclusiveness of kprobes. Consider the following 
> > > >scenario,
> > > >
> > > >utility 1 inserts kprobe k1 with handler h1 at address A
> > > >utility 2 wants to insert kprobe k2 with handler h2 at the same address A
> > > >
> > > >In this situation if we do _not_ fail user 2 and add handler h2 to the 
> > > >existing kprobe, what might happen is that if at the hit of kprobe, the
> > > >handler h1 can modify some data and things might not be as expected 
> > > >by h2. [...]
> 
> It seems to me that we're really stretching into the world of the
> hypothetical to find some justification for the status quo.  Do there
> exist any such probes that you know of?  Are they such that if an
> immediately adjacent instruction was made the subject of the "utility
> 2" probe, that this hypothetical scenario would then work?
> 

Alright, I agree that the adjacent instruction kprobes (and they are possible
even with the current kprobe mechanism) vulnerability is the same as having
kprobes at the same address. And my doubt was theoretical and not based on some
practical scenario.


-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990