netdev - Re: [PATCH net-next] net: restore DSA behavior of not overriding ndo_get_phys_port

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: <6db74106-af90-deac-907d-9f0c971ec698@gmail.com>
Date:   Wed, 22 Jul 2020 15:11:09 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        andrew@...n.ch, vivien.didelot@...il.com, jiri@...lanox.com,
        edumazet@...gle.com, ap420073@...il.com, xiyou.wangcong@...il.com,
        maximmi@...lanox.com, mkubecek@...e.cz, richardcochran@...il.com
Subject: Re: [PATCH net-next] net: restore DSA behavior of not overriding
 ndo_get_phys_port_name if present

On 7/22/20 3:06 PM, Vladimir Oltean wrote:
> On Wed, Jul 22, 2020 at 02:53:28PM -0700, Florian Fainelli wrote:
>> On 7/22/20 1:53 PM, Vladimir Oltean wrote:
>>> Prior to the commit below, dsa_master_ndo_setup() used to avoid
>>> overriding .ndo_get_phys_port_name() unless the callback was empty.
>>>
>>> https://elixir.bootlin.com/linux/v5.7.7/source/net/dsa/master.c#L269
>>>
>>> Now, it overrides it unconditionally.
>>>
>>> This matters for boards where DSA switches are hanging off of other DSA
>>> switches, or switchdev interfaces.
>>> Say a user has these udev rules for the top-level switch:
>>>
>>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p0", NAME="swp0"
>>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p1", NAME="swp1"
>>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p2", NAME="swp2"
>>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p3", NAME="swp3"
>>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p4", NAME="swp4"
>>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p5", NAME="swp5"
>>>
>>> If the DSA switches below start randomly overriding
>>> ndo_get_phys_port_name with their own CPU port, bad things can happen.
>>> Not only may the CPU port number be not unique among different
>>> downstream DSA switches, but one of the upstream switchdev interfaces
>>> may also happen to have a port with the same number. So, we may even end
>>> up in a situation where all interfaces of the top-level switch end up
>>> having a phys_port_name attribute of "p0". Clearly not ok if the purpose
>>> of the udev rules is to assign unique names.
>>>
>>> Fix this by restoring the old behavior, which did not overlay this
>>> operation on top of the DSA master logic, if there was one in place
>>> already.
>>>
>>> Fixes: 3369afba1e46 ("net: Call into DSA netdevice_ops wrappers")
>>> Signed-off-by: Vladimir Oltean <olteanv@...il.com>
>>> ---
>>> This is brain-dead, please consider killing this and retrieving the CPU
>>> port number from "devlink port"...
>>
>> That is fair enough. Do you want to submit such a change while you are
>> at it?
>>
> 
> If I'm getting you right, you mean I should be dropping this patch, and
> send another one that deletes dsa_ndo_get_phys_port_name()?
> I would expect that to be so - the problem is the fact that we're
> retrieving the number of the CPU port through an ndo of the master
> interface, it's not something we can fix by just calling into devlink
> from kernel side. The user has to call into devlink.

Yes, that is what I meant, that an user should call the appropriate
devlink command to obtain the port number, this particular change has
caused more harm than good, and the justification for doing it in the
first place was weak to begin with.
-- 
Florian