Got suggestions to reduce the locks in stacker.c?

dwheelerat_private

Greg KH <gregat_private> said:

 > I would hate to see the benchmark runs with a lock being grabbed for
 > every security hook.  I think you just set back the whole "no more BKL"
 > posse a few years  [:)]

Suggestions welcome.  Got any?

One approach is my previous approach - if I can force
writing of pointers to be atomic (any suggestions on how to do so?),
and people are willing to accept certain weaknesses (e.g., tasks
in the process of catching up may call or also call dummy operations),
it doesn't really need the locks at all.
Forcing a module to "never quite unload" also solves much.

I think the same problem ("pointer writing isn't atomic on
all architectures") means that LSM ITSELF will fail
on those architectures. In security.c, register_security has this line:
         security_ops = ops;
If writing a pointer isn't atomic, then security_ops could
be a half-written pointer and called by a hook before it
completes writing.  Disastrous. Again, is there any way to ensure that a
pointer write is atomic??  Or is there something else protecting this
case, or a special case that works on the nasty architectures
(e.g., fixed address location).

You can have it both ways.
Since you can load different multiplexors,
I could make this a #define, and compile it both ways
(e.g., creating "stacker" and "safe_stacker" modules).

This is really a symptom of the general complexities
of loadable modules.

I looked over Linux's lock implementation, and
on single-processor x86's, when write contention is rare (true here) the
rw_semaphor implementation in Linux is actually quite impressive
as these things go. It's quite clever.
Of course, not locking is MUCH faster than locking,
and multiple processor systems' complications with
cache lines that would really limit performance for real SMP systems.

--- David A. Wheeler
     dwheelerat_private

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