Re: [RFC] [PATCH] To refuse users from probing preempt_schedule()

[Srinivasa DS <srinivasa@in.ibm.com>]

On Monday 25 February 2008 11:50:24 am Dave Hansen wrote:
> On Mon, 2008-02-25 at 11:27 +0530, srinivasa wrote:
> > This patch prohibits user from probing preempt_schedule(). One way of
> > prohibiting the user from probing functions is by marking such
> > functions with __kprobes. But this method doesn't work for those
> > functions, which are already marked to different section like
> > preempt_schedule() (belongs to __sched section). So we use blacklist
> > approach to refuse user from probing these functions.
>
> preempt_schedule() does sound really, really important.  But, what kinds
> of functions can't be kprobed?  
      
Normally we don't allow user to probe those functions, which are used by 
kprobes internally while registering probe on user specified address.  For 
example kprobes internally makes use of preempt_disable()(this in turn calls 
add_preempt_count()), so we prohibit users from probing add_preempt_count() 
function.  To get comprehensive list of functions which are prohibited from 
probing, please have a look at functions which are marked under __kprobes. 
 
> It would be nice to give that blacklist 
> a nice comment on the topic. :)

Yes, I  have added comments on the blacklist approach in 
     1)init_kprobes(), where we populate entries  for kprobe blacklist.
     2) in_kprobe_function(), where we verify the user specified address with 
the start and end of the blacklisted function.

>
> Also, have you strained your brains to think of other functions that
> this should be applied to?  Is it just for functions that are sensitive
> and already have an assigned section? 

Yes, this kprobes blacklist approach is only for those functions which are 
sensitive and are already assigned to different sections. Right now, 
there is no other function, except preempt_schedule() which satisfies above 
condition. But in future if we encounter any such functions we surely add 
them kprobe blacklist.