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 22:48:45 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>,
        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 Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote:
> 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.

For a switch, there are four stages, not two:

1. The out-of-reset state, which from what I've seen seems to be to
   behave like a dumb switch.

2. The boot loader state, which is generally the same as the
   out-of-reset state.

3. The OS-booting state, which for a DSA switch in Linux isolates each
   port from each other.

4. The OS-booted state, which depends on the system configuration.

If you are setting up a switch in a STP environment, you _have_ to be
aware of all of those states, and plan your network accordingly.
While it's possible to argue that the boot loader should isolate the
ports, it may be that the system gets hosed to the point that the boot
loader is unable to run - then you have a switch operating in a STP
environment acting as a dumb switch.

The same actually goes for many switches - consider your typical DSL
router integrated with a four port switch.  By default, that switch
forwards traffic between each port.  If you've setup the ports to be
isolated, each time the router is rebooted (e.g., due to a
configuration change) it will forward traffic between all ports until
the routers OS has finished booting and applied the switch
configuration.

What I'm basically saying is that if you're going to the point of
using such hardware in a STP environment, you _must_ pay attention
to the behaviour of the hardware through all phases of its operation
and consider the consequences should it fail in any of those phases.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up