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: <CAK7LNARvQUPPBzdq7ac67h-xhB6tHZ4WPzBHZy+c3iHE_bi_Fg@mail.gmail.com>
Date:   Fri, 17 May 2019 13:45:11 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Cc:     Sam Ravnborg <sam@...nborg.org>, Arnd Bergmann <arnd@...db.de>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jessica Yu <jeyu@...nel.org>,
        Lucas De Marchi <lucas.de.marchi@...il.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Michael Schmitz <schmitzmic@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Rusty Russell <rusty@...tcorp.com.au>,
        Kees Cook <keescook@...omium.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kbuild: check uniqueness of module names

On Fri, May 17, 2019 at 1:29 PM Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
>
> In the recent build test of linux-next, Stephen saw a build error
> caused by a broken .tmp_versions/*.mod file:
>
>   https://lkml.org/lkml/2019/5/13/991
>
> drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
> basename, and there is a race in generating .tmp_versions/asix.mod
>
> Kbuild has not checked this before, and it suddenly shows up with
> obscure error message when this kind of race occurs.
>
> Non-unique module names cause various sort of problems, but it is
> not trivial to catch them by eyes.
>
> Hence, this script.
>
> It checks not only real modules, but also built-in modules (i.e.
> controlled by tristate CONFIG option, but currently compiled with =y).
> Non-unique names for built-in modules also cause problems because
> /sys/modules/ would fall over.
>
> I tested allmodconfig on the latest kernel, and it detected the
> following:
>
> warning: same basename if the following are built as modules:
>   drivers/regulator/88pm800.ko
>   drivers/mfd/88pm800.ko
> warning: same basename if the following are built as modules:
>   drivers/gpu/drm/bridge/adv7511/adv7511.ko
>   drivers/media/i2c/adv7511.ko
> warning: same basename if the following are built as modules:
>   drivers/net/phy/asix.ko
>   drivers/net/usb/asix.ko
> warning: same basename if the following are built as modules:
>   fs/coda/coda.ko
>   drivers/media/platform/coda/coda.ko
> warning: same basename if the following are built as modules:
>   drivers/net/phy/realtek.ko
>   drivers/net/dsa/realtek.ko
>
> Reported-by: Stephen Rothwell <sfr@...b.auug.org.au>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
> Reviewed-by: Kees Cook <keescook@...omium.org>
> ---


One more question popped up.

External modules are out of scope of the community,
but it is possible that people create an external module
that happens to have the same name as an upstream driver.

drivers/this/is/upstream/subsystem/foo.ko
/home/fred/my/own/external/module/foo.ko

Is modprobe confused in this case too?

Perhaps, checking for the M= build
might be good too...



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ