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:   Wed, 5 Jun 2019 01:03:27 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Florian Fainelli <f.fainelli@...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 Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin
<linux@...linux.org.uk> wrote:
>
> 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

Hi Russell,

The dumb switch was just an example. The absolute same thing (unwanted
PHY connection) applies to regular NICs. I am not aware of any setting
that makes the MAC ignore frames as long as they observe the
appropriate MII spec. And the hardware will go on to process those
frames, potentially calling into the operating system and making it
susceptible to denial of service. That is unless you set up your
buffer rings/queues/whatever in the ndo_open/ndo_close callbacks.
The point is that having a way to make a link dead/have it dead by
default is the easiest way to prevent a lot of problems. Call that
policy, whatever, but I think at the very least the Linux kernel
should have a way to operate in this mode (if not even be the default
one, unless the user knows better).

Regards,
-Vladimir