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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 30 Apr 2022 22:19:25 +0200 From: Heiner Kallweit <hkallweit1@...il.com> To: Peter Geis <pgwipeout@...il.com>, Andrew Lunn <andrew@...n.ch> Cc: "Russell King (Oracle)" <linux@...linux.org.uk>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>, Linux Kernel Network Developers <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v1] net: phy: fix motorcomm module automatic loading On 30.04.2022 18:31, Peter Geis wrote: > On Sat, Apr 30, 2022 at 11:52 AM Andrew Lunn <andrew@...n.ch> wrote: >> >>> Good Morning, >>> >>> After testing various configurations I found what is actually >>> happening here. When libphy is built in but the phy drivers are >>> modules and not available in the initrd, the generic phy driver binds >>> here. This allows the phy to come up but it is not functional. >> >> What MAC are you using? > > Specifically Motorcomm, but I've discovered it can happen with any of > the phy drivers with the right kconfig. > >> >> Why is you interface being brought up by the initramfs? Are you using >> NFS root from within the initramfs? > > This was discovered with embedded programming. It's common to have a > small initramfs, or forgo an initramfs altogether. Another cause is a > mismatch in kernel config where phylib is built in because of a > dependency, but the rest of the phy drivers are modular. > The key is: > - phylib is built in > - ethernet driver is built in > - the phy driver is a module > - modules aren't available at probe time (for any reason). > > In this case phylib assumes there is no driver, when the vast majority > of phys now have device specific drivers.It seems this is an unsafe > assumption as this means there is now an implicit dependency of the > device specific phy drivers and phylib. It just so happens to work > simply because both broadcom and realtek, some of the more common > phys, have explicit dependencies elsewhere that cause them to be built > in as well. > Because you mention the realtek phy driver: Users reported similar issues like you if r8169 MAC driver is built-in (or r8169 module is in initramfs) but realtek phy driver is not. There's no direct code dependency between r8169 and realtek phy driver, therefore initramfs-creating tools sometimes missed to automatically include the phy driver in initramfs. To mitigate this r8169 has the following: MODULE_SOFTDEP("pre: realtek"); This isn't strictly needed but some initramfs-creating tools consider such soft dependencies when checking what should be included in initramfs. If some other MAC is used with a Realtek PHY, then you may still see the described issue. As Andrew wrote: Eventually it's a userspace responsibility to ensure that all needed modules are included in initramfs. >>>> What normally happens is that the kernel loads, maybe with the MAC >> driver and phylib loading, as part of the initramfs. The other modules >> in the initramfs allow the root filesystem to be found, mounted, and >> pivoted into it. The MAC driver is then brought up by the initscripts, >> which causes phylib to request the needed PHY driver modules, it loads >> and all is good. >> >> If you are using NFS root, then the load of the PHY driver happens >> earlier, inside the initramfs. If this is you situation, maybe the >> correct fix is to teach the initramfs tools to include the PHY drivers >> when NFS root is being used? >> >> Andrew
Powered by blists - more mailing lists