netdev - Re: mv88e6240 configuration broken for B850v3

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: <20211206214428.qaavetaml2thggqo@skbuf>
Date:   Mon, 6 Dec 2021 23:44:28 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Martyn Welch <martyn.welch@...labora.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, kernel@...labora.com
Subject: Re: mv88e6240 configuration broken for B850v3

On Mon, Dec 06, 2021 at 08:18:30PM +0000, Russell King (Oracle) wrote:
> > If we're going to impersonate phylink we could at least provide the same
> > arguments as phylink will.
> 
> What is going on here in terms of impersonation is entirely reasonable.
> 
> The only things in this respect that phylink guarantees are:
> 
> 1) The MAC/PCS configuration will not be substantially reconfigured
>    unless a call to mac_link_down() was made if a call to mac_link_up()
>    was previously made.

The wording here is unclear. Did you mean "When the MAC/PCS configuration
is substantially reconfigured and the last call was a mac_link_up(), a
follow-up call to mac_link_down() will also be made"?

And what do you mean by "substantially reconfigured"?
phylink_major_config called from the paths that aren't phylink_mac_initial_config
(because that happens with no preceding call to either mac_link_down or
mac_link_up), right?

> 2) The arguments to mac_link_down() will be the same as the preceeding
>    mac_link_up() call - in other words, the "mode" and "interface".

Does this imply that "there will always be a preceding mac_link_up to
every mac_link_down call"? Because if it does imply that, DSA violates it.

> Phylink does *not* guarantee that a call to mac_link_up() or
> mac_config() will have the same "mode" as a preceeding call to
> mac_link_down(), in the same way that "interface" is not guaranteed.
> This has been true for as long as we've had SFPs that need to switch
> between MLO_AN_INBAND and MLO_AN_PHY - e.g. because the PHY doesn't
> supply in-band information.
> 
> So, this has uncovered a latent bug in the Marvell DSA code - and
> that is that mac_config() needs to take care of the forcing state
> after completing its configuration as I suggested in my previous
> reply.
> 
> There is also the question whether the automatic fetching of PHY
> status information by the hardware should be regarded as a form of
> in-band by phylink, even though it isn't true in-band - but from
> the software point of view, the PPU's automatic fetching is not
> materially different from what happens with SGMII.
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!