netdev - Re: Cutting the link on ndo_stop - phy_stop or phy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+h21hrqsH9FYtTOrCV+Bb0YANQvSnW9Uq=SoS7AJv9Wcw3A3w@mail.gmail.com>
Date:   Wed, 5 Jun 2019 00:29:47 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "linux@...linux.org.uk" <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ioana Ciornei <ioana.ciornei@....com>
Subject: Re: Cutting the link on ndo_stop - phy_stop or phy_disconnect?

On Wed, 5 Jun 2019 at 00:12, Andrew Lunn <andrew@...n.ch> wrote:
>
> > But now the second question: between a phy_connect and a phy_start,
> > shouldn't the PHY be suspended too? Experimentally it looks like it
> > still isn't.
>
> This is not always clear cut. Doing auto-neg is slow. Some systems
> want to get networking going as fast as possible. The PHY can be
> strapped so that on power up it starts autoneg. That can be finished
> by the time linux takes control of the PHY, and it can take over the
> results, rather than triggering another auto-neg, which will add
> another 3 seconds before the network is up.
>
> If we power the PHY down, between connect and start, we loose all
> this.
>
> I don't remember anybody submitting patches because the PHY passed
> frames to the MAC too early. So i don't think there is much danger
> there.
>
>         Andrew

Hi Andrew,

Call me paranoid, but I think the assumption you're making is that
every time you have an Ethernet link, you want it.
Consider the case where you have an Ethernet switch brought up by
U-boot (where it does dumb switching, with no STP, nothing) and the
system power-cycles in a network with loops.
If the operating system has no way to control whether the Ethernet
ports are administratively up, anything can happen... I don't think
it's a bad idea to err on the safe side here. Even in the case of a
regular NIC, packets can go up quite a bit in the MAC, possibly even
triggering interrupts on the cores, when the interface should have
been otherwise "down".

Regards,
-Vladimir