netdev - RFC: Handle hard module dependencies that are not symbol-based (r8169 + realtek)

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-next>] [day] [month] [year] [list]

Message-ID: <f8e3f271-82df-165f-63f1-6df73ba3d59c@gmail.com>
Date:   Wed, 1 Apr 2020 23:20:20 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Lucas De Marchi <lucas.demarchi@...el.com>,
        Jessica Yu <jeyu@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-module@...r.kernel.org,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RFC: Handle hard module dependencies that are not symbol-based (r8169
 + realtek)

Currently we have no way to express a hard dependency that is not
a symbol-based dependency (symbol defined in module A is used in
module B). Use case:
Network driver ND uses callbacks in the dedicated PHY driver DP
for the integrated PHY (namely read_page() and write_page() in
struct phy_driver). If DP can't be loaded (e.g. because ND is in
initramfs but DP is not), then phylib will use the generic
PHY driver GP. GP doesn't implement certain callbacks that are
needed by ND, therefore ND's probe has to bail out with an error
once it detects that DP is not loaded.
We have this problem with driver r8169 having such a dependency
on PHY driver realtek. Some distributions have tools for
configuring initramfs that consider hard dependencies based on
depmod output. Means so far somebody can add r8169.ko to initramfs,
and neither human being nor machine will have an idea that
realtek.ko needs to be added too.

Attached patch set (two patches for kmod, one for the kernel)
allows to express this hard dependency of ND from DP. depmod will
read this dependency information and treat it like a symbol-based
dependency. As a result tools e.g. populating initramfs can
consider the dependency and place DP in initramfs if ND is in
initramfs. On my system the patch set does the trick when
adding following line to r8169_main.c:
MODULE_HARDDEP("realtek");

I'm interested in your opinion on the patches, and whether you
maybe have a better idea how to solve the problem.

Heiner

View attachment "0001-depmod-add-helper-mod_add_dep_unique.patch" of type "text/plain" (1584 bytes)

View attachment "0001-module-add-MODULE_HARDDEP.patch" of type "text/plain" (1707 bytes)

View attachment "0002-depmod-add-depmod_load_harddeps.patch" of type "text/plain" (2033 bytes)