Re: Implementing hooks

karymat_private

I've been meaning to follow up on this for a while.

Greg KH wrote:
> 
> On Thu, Apr 19, 2001 at 11:17:46AM -0400, David Wheeler wrote:
> > Option 1:  ALWAYS call a function, which may just return.
> >   err = security_ops->ioperm();
> 
> This is the fastest on the majority of todays processors.  Linus said
> this was the preferred method at the 2.5 meeting for this interface.
> Listen to the session on the web if you want, other people validate this
> with specific examples.

I understand your desire to stick by Linus' requirements, but I don't
think that this should limit the suggestion of faster implementations.
If the jump-over-hook-by-default technique suggested earlier is used and
comes up with zero overhead when not hooked instead of 0.x% using
the "err = security_ops->ioperm()" technique, my guess is that there
will be interest.

> Remember, this is _core_ kernel code.  It _has_ to work across all
> platform types.  The only way for this is either a generic C
> implementation, or arch specific code for every arch.  And have you seen
> how may different platforms are supported in the 2.4 kernel these days?

This is definitely a good point. Which brings us to using macros instead
of C code. In such a scenario, it should be fairly easy to have common
macro where the macro resolves in a C call. There could also be an architecture-
specific macro definition whereby the macros generate dynamically
modifiable code. The responsability of implementing the optimized
macros would lie with the people maintaining the code for the given
arch. Hence, LSM wouldn't provide the optimized macros (although it
could provide some). Rather, if, for instance, the PPC ppl want optimized
hooks, they can implement the suggested optimization, otherwise they have
the standard call to a C function.

Again, this falls in line with the suggestion I made earlier about
inserting an unconditional jump prior to the hook code by default.
The jump would be overwritten with NOPs to activate the hooks. Dynamically,
this should make zero difference between a running "vanilla" kernel and
a running kernel with the hooks inserted (but not actually activated).

In any case, just thought you'd be interested.

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karymat_private
      Embedded and Real-Time Linux Expert
===================================================

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module