lkml.org 
[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2005-03-22 13:28    [W:9.901 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site