netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49ed2198d5cf219086eee24ba1ac640b60d32a1f.camel@siemens.com>
Date:   Mon, 23 Jan 2023 19:10:14 +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: Re: dsa: phy started on dsa_register_switch()

Thank you Florian for the quick reply!

On Mon, 2023-01-23 at 10:57 -0800, Florian Fainelli wrote:
> > 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.
> 
> If you are concerned about security with a switch, then clearly the 
> switch should have an EEPROM which configures it to isolate all of
> the 
> ports from one another, and possibly do additional configuration to 
> prevent any packets from leaking. The PHY and Ethernet link being
> active 
> would not be a reliable way to ensure you start up in a secure state,
> it 
> may participate into it, but it is not the only thing you can rely
> upon.
> 

Absolutely! This was merely an indication problem, people want to see
that disabled ports are visibly disabled from the outside, and we
want to bring the netdev state in sync with LED indication.

> > 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.
> 
> This is what is advised for Ethernet controller drivers to do, but is
> not strictly enforced or true throughout the entire tree, that is, it
> depends largely upon whether people writing/maintaining those drivers
> are sensitive to that behavior.
> 

You are right, this behavior is up to the individual drivers, there
is no guarantee for this in core.

[...]

> > 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.
> 
> That seems to be exactly the behavior you want based upon the
> previous 
> paragraph as it indicates that the PHY has been powered down.
> 

Maybe you are right and we should just toggle IFF_UP once on boot
to sync the state, as this behavour is not unified...
Thanks for looking into this!

> > Is this behaviour intended? Shall I try to develop patches moving
> > phylink_.*phy_connect to dsa_slave_open() and something similar
> > for CPU port?
> 
> Yes this was intentional since the beginning to speed up 
> auto-negotiation, and it dates back to when DSA was brought into the 
> kernel circa 2008.
> 
> We are almost guaranteed to be breaking someone's behavior if we 
> postpone the connection to the PHY, however we could introduce a flag
> and make the deferring of connecting to the PHY to ndo_open() a
> driver 
> by driver decision when proven this has no ill effect.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com