On Wed, Aug 24, 2005 at 06:20:31PM -0700, Chris Wright wrote:
> Call security hooks conditionally if the security_op is filled out.
> Branches can be more efficient than the unconditional indirect function
> call. Inspired by patch from Kurt Garloff <garloff@private>.
>
> Signed-off-by: Chris Wright <chrisw@private>
> ---
> include/linux/security.h | 825 +++++++++++++++++++++++------------------------
> 1 files changed, 411 insertions(+), 414 deletions(-)
>
> Index: linus-2.6/include/linux/security.h
> ===================================================================
> --- linus-2.6.orig/include/linux/security.h
> +++ linus-2.6/include/linux/security.h
> @@ -1264,10 +1264,10 @@ static inline int security_init(void)
> static inline int security_ptrace (struct task_struct * parent, struct task_struct * child)
> {
> #ifdef CONFIG_SECURITY
> - return security_ops->ptrace (parent, child);
> -#else
> - return cap_ptrace (parent, child);
> + if (security_ops->ptrace)
> + return security_ops->ptrace(parent, child);
You did not like my macro abuse, apparently.
That's too bad, as it allowed you to do changes without changing
hundreds of lines of code.
Just one remark:
Make sure you don't set security_ops->XXX ever back to NULL or you
might take an oops.
Security module unloading is racy and always has been. It's not well
defined at what point in time the new functions become effective.
And we certainly don't want to use locking for performance reasons.
One could think of using RCU, though, thus the security_ops pointer
would only be changed after all CPUs schedule()d ...
In my version of the patches, I maintained the capability_security_ops
structure fully filled-in and pointed security_ops to it, so you'll
always have a valid function pointer. If you wanted to avoid a pointer
compare, I had an integer to look at ...
Thanks for your patches!
--
Kurt Garloff <kurt@private> [Koeln, DE]
Physics:Plasma modeling <garloff@private> [TU Eindhoven, NL]
Linux: SUSE Labs (Director) <garloff@private> [Novell Inc]
This archive was generated by hypermail 2.1.3 : Thu Aug 25 2005 - 17:37:45 PDT