linux-kernel - Re: [RFC] [PATCH] To refuse users from probing preempt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200802251225.53732.srinivasa@in.ibm.com>
Date:	Mon, 25 Feb 2008 12:25:53 +0530
From:	Srinivasa DS <srinivasa@...ibm.com>
To:	Dave Hansen <haveblue@...ibm.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>, ananth@...ibm.com,
	Jim Keniston <jkenisto@...ibm.com>, srikar@...ux.vnet.ibm.com
Subject: Re: [RFC] [PATCH] To refuse users from probing preempt_schedule()

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/