Messages in this thread |  | | Date | Fri, 13 Sep 2002 17:55:00 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [RFC] Raceless module interface |
| |
Hi,
On Fri, 13 Sep 2002, Daniel Phillips wrote:
> > The exit itself can fail as well, so it has to be done by the module code > > anyway (until it suceeds). > > That's debatable. Arguably, a failed ->module_cleanup() should be > retried on every rmmod -a, but expecting module.c to just keep > retrying mindlessly on its own sounds too much like a busy wait.
That's not what I meant, if module_init fails the module goes directly to the cleanup state and the module code calls module_exit. Depending on this return value it continues to the exit state. Further exit attempts (if necessary) are done on user request.
> > What DoS opportunities are there? > > Suppose the module exit relies on synchronize_kernel. The attacker > can force repeated synchronize_kernels, knowing that module.c will > mindlessly do a synchronize_kernel every time a module init fails, > whether needed or not. Each synchronize_kernel takes an unbounded > amount of time to complete, across which module.c holds a lock.
This can't happen:
if (hook) { hook = NULL; synchronize(); }
> > Module init failure is the exception > > case and usally needs further attention, so we could actually disable > > further attempts to load this module, unless the user tells us > > specifically so. > > Sure, you can fix it by lathering on more complexity. What you have > to do is explain why we should do that, when there is a simpler and > faster approach that doesn't introduce the problem in the first > place.
It doesn't add any complexity (at least not to the kernel). A simple approach might be that a failed kernel module cannot be loaded with modprobe anymore, this sort of policy can be done in userspace.
> I take it that the points you didn't reply to are points that you > agree with? (The main point being, that we both advocate a simple, > two-method interface for module load/unload.)
Basically yes, it's just that your initial RFC was more confusing than helpful.
bye, Roman
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |