netdev - dsa: phy started on dsa_register

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: <f95cdab0940043167ddf69a4b21292ee63fc9054.camel@siemens.com>
Date:   Mon, 23 Jan 2023 18:35:32 +0000
From:   "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To:     "olteanv@...il.com" <olteanv@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "andrew@...n.ch" <andrew@...n.ch>
CC:     "Freihofer, Adrian" <adrian.freihofer@...mens.com>
Subject: dsa: phy started on dsa_register_switch()

Dear DSA maintainers,

I've been puzzled by the fact ports of the DSA switches are enabled on
bootup by default (PHYs configured, LEDs ON, etc) in contrast to the
normal Ethernet ports.

Some people tend to think this is a security issue that port is "open"
even though no configuration has been performed on the port, so I
looked into the differences between Ethernet drivers and DSA
infrastructure.

Traditionally phylink_of_phy_connect() and phylink_connect_phy() are
being called from _open() callbacks of the Ethernet drivers so
as long as the Ethernet ports are !IFF_UP PHYs are not running,
LEDs are OFF, etc.

Now with DSA phylink_of_phy_connect() is being called by
dsa_slave_phy_setup() which in turn is being called already in
dsa_slave_create(), at the time a switch is being DT-parsed and
created.

This confuses users a bit because neither CPU nor user ports have
been setup yet from userspace via netlink, yet the LEDs are ON.

The things get worse when a user performs
"ip link set dev lan1 up; ip link set dev lan1 down", because now
the LEDs go OFF.

Is this behaviour intended? Shall I try to develop patches moving
phylink_.*phy_connect to dsa_slave_open() and something similar
for CPU port?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com