Re: Implementing hooks

karymat_private

David Wheeler wrote:
> 
> I agree with Andrew Morgan <morganat_private>'s proposal to
> use C preprocessor macros to implement hook insertions and returns.  That way,
> you can optimize differently for different processor types and implement
> rival designs.  In addition, Linus has previously stated that he
> does NOT want code littered with #ifdef's.. if you need multiple #ifdefs that
> do the same thing, he'd prefer to have it hidden in a macro call.
> That way, the #ifdef is confined to a single location (the macro definition).
> The main reason to do this, however, would be so that you can
> separate HOW hooks are implemented from the decision on WHERE to put them.

Yes, this is the best approach and is already used for the LTT hooks
(no marketing, just statement of fact).

> 
> And frankly, it appears that there are LOTS of ways to implement hooks,
> and which is better is almost certainly architecture-dependent.
> For many pipelined systems, any insertion of a branch is likely to
> cause a stall... unless it does speculative execution & has the resources
> to do it... unless, unless, unless.  Here are a few implementation
> possibilities that I see for hooks (there are probably more), which
> argues for encapsulating the hook mechanism to permit compile-time
> selection the best mechanism:

There's one approach you don't list and that is probably the simplest one
while remaining extremely efficient:
The use of default jmps over the hook code. Using this, the default behavior
compiled within the kernel would be a jump over the code implementing
the hook. Something like:
A()
B()
HOOK()
C()

Would yield:
call A
call B
jump label1234
call hook
label1234:
call C

To activate the hook, one would only need to overwrite the "jump label1234"
by NOPs. Modern CPUs are quite good at taking care of unconditionnal branches
and, since the branch distances would be quite short, results may be even better
than adding a bunch of NOPs.

> 
> That's a valid point.  I would say, then, that a non-self-modifying
> approach would at least need to be available.  However, it's my understanding
> that few systems actually _RUN_ out of their ROMs.  So, if you separate
> the hook _implementation_ from the hook placement, you can have various
> hook implementation options.

Agreed.

===================================================
                 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