Re: [RFC] [PATCH] To refuse users from probing preempt_schedule()
From: Srinivasa DS
Date: Mon Feb 25 2008 - 01:56:07 EST
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/