lkml.org 
[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC] Raceless module interface
    Date
    On Friday 13 September 2002 17:13, Roman Zippel wrote:
    > Hi,
    >
    > On Fri, 13 Sep 2002, Daniel Phillips wrote:
    >
    > > > The exit function should always be called after the init function (even if
    > > > it failed, I don't do it in the patch, that's a bug). The fs init/exit
    > > > would like this then:
    > >
    > > Perhaps, but if so, the module itself should call the exit function in
    > > its failure path itself. Doing the full exit whether it needs to be
    > > done or not is wasteful and opens up new DoS opportunities.
    >
    > 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.

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

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

    > > In the example you give below you must rely on register_filesystem
    > > tolerating unregistering a nonexistent filesystem. That's sloppy at
    > > best, and you will have to ensure *every* helper used by ->exit is
    > > similarly sloppy.
    >
    > Why is that sloppy? E.g. kfree() happily accepts NULL pointers as well.

    That is sloppy. Different discussion.

    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.)

    --
    Daniel
    -
    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:0.025 / U:0.300 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site