[I am not sure whether my mail client handles list correctly, it is
possible that it doesn't. So apologies to everybody for broken threads,
line wraps, quotes...]
On 22/12/2004 18:31:04 "Serge E. Hallyn" wrote:
>Oh, no! Many hooks are allowed to sleep. I actually wanted to say that
>you can't assume they *won't* sleep, which is why you can't just do a
That is much better! :)
>as it sounds like you've found. But my approach performed pretty well on
>lmbench on a 4-way smp system, doing something like
>
>rcu_read_lock();
>list_for_each_entry_rcu() {
>increment m->ref_count;
>rcu_read_unlock();
>call m->hook();
>rcu_read_lock();
>decrement m->ref_count and free if necessary;
>}
>rcu_read_unlock();
Yes, I am doing something similar. The difference is I do:
atomic_dec_and_test(m->usecnt) and if true wake_up(&m->unload)
While my stacker_unregister_security is doing an:
list_del_rcu(&m->head);
wait_event(m->unload, atomic_read(&m->usecnt));
Therefore the module which tries ot unload itself will sleep until all
operations in progress finish, and only then be allowed to unload.
If I didn't miss something, you are firing away a call_rcu which will free
stacker structures associated with the module. But what is preventing the
stacked module itself to unload after mod_unreg_security (from it's
perspective) returns? Couldn't it unload itself while something is still
executing it's security hooks?
>What is the reason why the stacker on www.sf.net/projects/lsm-stacker
does
>not suffice?
Apart from above concernes there is none. But as mine was almost complete
before I got your email with the link I continue to work on it as an
exercise.
The one thing that by looking at your code I realised I missed is the
"alloc" hooks special handling. And I don't have all the fancy
functionality like sysfs and SELinux special case stuff.
Oh yes, one thing which I was trying to get right is to be completely
transparent. I don't see you are doing that in your stacker? Read below...
What I have done is the following:
When the stacker is loaded and no modules are stacked it calls the cap_*
hooks where implemented.
When a modules stacks, it calls my version of otherwise un-exported
security_fixup_ops (a small hack to get that one) so that the "dummy"
capabilities code is called instead of undefined hooks.
Both of the above is what I think is correct eg. the way kernel behaves
with no stacker.
All of that is completely futile from the point of kernel structures
security field not being correctly shared. You handle that in your kernel
patches, so the only long term hope is that your work gets accepted into
the kernel.
This archive was generated by hypermail 2.1.3 : Thu Dec 23 2004 - 02:55:49 PST