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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 4 Jun 2019 14:37:31 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>
Cc:     "linux@...linux.org.uk" <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...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 6/4/2019 2:29 PM, Vladimir Oltean wrote:
> 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".

The firmware/boot loader transition to a full fledged OS with a switch
is a tricky one to answer though, and there are no perfect answers
AFAICT. If your SW is totally hosed, you might want the switch to
forward traffic between all LAN ports (excluding WAN, otherwise you
expose your home devices to the outside world, whoops).

If your SW is fully operational, then the questions are:

- do you want a DSA like behavior in your boot loader, in that all ports
are separated but fully usable or do you want a dumb switch model where
any port can forward to the CPU/management port, without any tags or
anything (unmanaged mode)

- what happens during bootloader to OS handover, should the switch be
held in reset so as to avoid any possible indirect DMA into main memory
as much as power saving? Should nothing happen and let the OS wipe out
clean the setting left by the boot loader?

All of these are in the realm of policy and trade offs as far as
initializing/disruption goes, so there are no hard and fast answers.
-- 
Florian