linux-kernel - Re: kmod: add a sanity check on module loading

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]

Message-ID: <20170104024745.t3selvpcqcbtfxfs@jeyu>
Date:   Tue, 3 Jan 2017 18:47:45 -0800
From:   Jessica Yu <jeyu@...hat.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     shuah@...nel.org, rusty@...tcorp.com.au, ebiederm@...ssion.com,
        dmitry.torokhov@...il.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,
        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: kmod: add a sanity check on module loading

+++ Luis R. Rodriguez [08/12/16 11:49 -0800]:
>kmod has an optimization in place whereby if a some kernel code
>uses request_module() on a module already loaded we never bother
>userspace as the module already is loaded. This is not true for
>get_fs_type() though as it uses aliases.
>
>Additionally kmod <= v19 was broken -- it returns 0 to modprobe calls,
>assuming the kernel module is built-in, where really we have a race as
>the module starts forming. kmod <= v19 has incorrect userspace heuristics,
>a userspace kmod fix is available for it:
>
>http://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/libkmod/libkmod-module.c?id=fd44a98ae2eb5eb32161088954ab21e58e19dfc4
>
>This changes kmod to address both:
>
> o Provides the alias optimization for get_fs_type() so modules already
>   loaded do not get re-requested.
>
> o Provides a sanity test to verify modprobe's work
>
>This is important given how any get_fs_type() users assert success
>means we're ready to go, and tests with the new test_kmod stress driver
>reveal that request_module() and get_fs_type() might fail for a few
>other reasons. You don't need old kmod to fail on request_module() or
>get_fs_type(), with the right system setup, these calls *can* fail
>today.
>
>Although this does get us in the business of keeping alias maps in
>kernel, the the work to support and maintain this is trivial.
>Aditionally, since it may be important get_fs_type() should not fail on
>certain systems, this tightens things up a bit more.
>
>The TL;DR:
>
>kmod <= v19 will return 0 on modprobe calls if you are built-in,
>however its heuristics for checking if you are built-in were broken.
>
>It assumed that having the directory /sys/module/module-name
>but not having the file /sys/module/module-name/initstate
>is sufficient to assume a module is built-in.
>
>The kernel loads the inittstate attribute *after* it creates the
>directory. This is an issue when modprobe returns 0 for kernel calls
>which assumes a return of 0 on request_module() can give you the
>right to assert the module is loaded and live.
>
>We cannot trust returns of modprobe as 0 in the kernel, we need to
>verify that modules are live if modprobe return 0 but only if modules
>*are* modules. The kernel heuristic we use to determine if a module is
>built-in is that if modprobe returns 0 we know we must be built-in or
>a module, but if we are a module clearly we must have a lingering kmod
>dangling on our linked list. If there is no modules there we are *somewhat*
>certain the module must be built in.
>
>This is not enough though... we cannot easily work around this since the
>kernel can use aliases to userspace for modules calls. For instance
>fs/namespace.c uses fs-modulename for filesystesms on get_fs_type(), so
>these need to be taken into consideration as well.
>
>Using kmod <= 19 will give you a NULL get_fs_type() return even though
>the module was loaded... That is a corner case, there are other failures
>for request_module() though -- the other failures are not easy to
>reproduce though but fortunately we have a stress test driver to help
>with that now. Use the following tests:
>
> # tools/testing/selftests/kmod/kmod.sh -t 0008
> # tools/testing/selftests/kmod/kmod.sh -t 0009
>
>You can more easily see this error if you have kmod <= v19 installed.
>
>You will need to install kmod <= v19, be sure to install its modprobe
>into /sbin/ as by default the 'make install' target does not replace
>your own.
>
>This test helps cure test_kmod cases 0008 0009 so enable them.
>
>Reported-by: Martin Wilck <martin.wilck@...e.com>
>Reported-by: Randy Wright <rwright@....com>
>Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>

Back from travel today, apologies for the delay. Will be able to give
this a proper look this week.

Jessica