linux-kernel - Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161216075726.GD13946@wotan.suse.de>
Date:   Fri, 16 Dec 2016 08:57:26 +0100
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>, shuah@...nel.org,
        jeyu@...hat.com, rusty@...tcorp.com.au, ebiederm@...ssion.com,
        dmitry.torokhov@...il.com, acme@...hat.com, corbet@....net,
        martin.wilck@...e.com, mmarek@...e.com, hare@...e.com,
        rwright@....com, jeffm@...e.com, DSterba@...e.com,
        fdmanana@...e.com, neilb@...e.com, linux@...ck-us.net,
        rgoldwyn@...e.com, subashab@...eaurora.org, xypron.glpk@....de,
        keescook@...omium.org, atomlin@...hat.com, mbenes@...e.cz,
        paulmck@...ux.vnet.ibm.com, dan.j.williams@...el.com,
        jpoimboe@...hat.com, davem@...emloft.net, mingo@...hat.com,
        akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
        linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 09/10] kmod: add helpers for getting kmod count and limit

On Thu, Dec 15, 2016 at 05:56:19PM +0100, Petr Mladek wrote:
> On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote:
> > This adds helpers for getting access to the kmod count and limit from
> > userspace. While at it, this also lets userspace fine tune the kmod
> > limit after boot, it uses the shiny new proc_douintvec_minmax().
> > 
> > These knobs should help userspace more gracefully and deterministically
> > handle module loading.
> >
> > Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
> > ---
> >  include/linux/kmod.h |  8 +++++
> >  kernel/kmod.c        | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> >  kernel/sysctl.c      | 14 +++++++++
> >  3 files changed, 103 insertions(+), 2 deletions(-)
> 
> I am not sure if it is worth it. As you say in the 3rd patch,
> there was rather low limit for 16 years and nobody probably had
> problems with it.

Note, *probably* - ie, this could have gone unreported for a while, and
to be frank how can we know for sure a pesky module just did not load due
to this? In the case of get_fs_type() issue this can be fatal for a partition
mount, not a good example to wait to look forward to before we take this
serious.

I added the sysctl value mostly for read purposes, the count is probably
useless for any accounting to be done in userspace due to delays this
reading and making this value useful in userspace can have, I can nuke
that. The kmod-limit however seems very useful so that userspace knows
how to properly thread *safely* modprobe calls more deterministically.

Adding write support to let one bump the limit was just an easy convenience
possible given the read support was being added, but its use should
really only be useful for testing purposes post bootup given that the
real value in the limit will be important at boot time prior to the sysctl
parsing. The real know tweak which should be used in case of issues is
the module parameter added earlier.

So I could drop the kmod-count, and just make the kmod-limit read-only.
Thoughts?

> Anyway, it seems that such know should also get documented in
> Documentation/sysctl/kernel.txt

Will do if we keep them, thanks.

  Luis