linux-kernel - Re: [PATCH v2 4/5] kmod: add helpers for getting kmod 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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 26 May 2017 22:27:31 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Tom Gundersen <teg@...m.no>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>, akpm@...ux-foundation.org,
        jeyu@...hat.com, shuah@...nel.org, rusty@...tcorp.com.au,
        ebiederm@...ssion.com, acme@...hat.com, corbet@....net,
        martin.wilck@...e.com, mmarek@...e.com, pmladek@...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,
        alan@...ux.intel.com, tytso@....edu, gregkh@...uxfoundation.org,
        torvalds@...ux-foundation.org, linux-kselftest@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/5] kmod: add helpers for getting kmod limit

On Thu, May 25, 2017 at 05:56:51PM -0700, Dmitry Torokhov wrote:
> On Thu, May 25, 2017 at 05:16:29PM -0700, Luis R. Rodriguez wrote:
> > This adds helpers for getting access to the kmod limit from
> > userspace. This knob should help userspace more gracefully and
> > deterministically handle module loading.
> 
> I think more details is needed before we add a new ABI to the kernel.
> Why can't userspace submit as much as it wants and the kernel decide how
> much it will service at once?

I suppose I should clarify on the commit log then, that without this heuristic
of #ifdef get_kmod_umh_limit -- *iff* userspace today is allowing more than 50
threads it can mean userspace is allowing a modprobe to fail. Check the results
of test 0008 and 0009 on dmesg, you can end up with really unexpected results.

This knob enables userspace to gracefully send in as many requests as allowed.
I guess this could just be a kernel revision check...  given that once
throttling go in it can be as crazy as it wants.

Also I suppose one could argue that *since* this has not been a real issue
*yet* (we assume), the old userspace of sending as many requests as it needs
is fine.

Will drop this!

  Luis