linux-kernel - Re: [RFC PATCH] net: dsa: microchip: Prevent overriding of HSR port forwarding

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 for Android: free password hash cracker in your pocket

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

Message-ID: <a838b848-8633-4312-b246-17af9175535c@kontron.de>
Date: Wed, 13 Aug 2025 17:57:02 +0200
From: Frieder Schrempf <frieder.schrempf@...tron.de>
To: Łukasz Majewski <lukma@...ladev.com>,
 Frieder Schrempf <frieder@...s.de>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
 Paolo Abeni <pabeni@...hat.com>, UNGLinuxDriver@...rochip.com,
 Vladimir Oltean <olteanv@...il.com>, Woojung Huh
 <woojung.huh@...rochip.com>, Florian Fainelli
 <florian.fainelli@...adcom.com>, Jesse Van Gavere <jesseevg@...il.com>,
 Oleksij Rempel <o.rempel@...gutronix.de>,
 Pieter Van Trappen <pieter.van.trappen@...n.ch>,
 "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
 Simon Horman <horms@...nel.org>, Tristram Ha <tristram.ha@...rochip.com>,
 Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Subject: Re: [RFC PATCH] net: dsa: microchip: Prevent overriding of HSR port
 forwarding

Am 13.08.25 um 17:45 schrieb Łukasz Majewski:
> [Sie erhalten nicht h?ufig E-Mails von lukma@...ladev.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]
> 
> Hi Frieder,
> 
>> From: Frieder Schrempf <frieder.schrempf@...tron.de>
>>
>> The KSZ9477 supports NETIF_F_HW_HSR_FWD to forward packets between
>> HSR ports. This is set up when creating the HSR interface via
>> ksz9477_hsr_join() and ksz9477_cfg_port_member().
>>
>> At the same time ksz_update_port_member() is called on every
>> state change of a port and reconfiguring the forwarding to the
>> default state which means packets get only forwarded to the CPU
>> port.
>>
>> If the ports are brought up before setting up the HSR interface
>> and then the port state is not changed afterwards, everything works
>> as intended:
>>
>>   ip link set lan1 up
>>   ip link set lan2 up
>>   ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision
>> 45 version 1 ip addr add dev hsr 10.0.0.10/24
>>   ip link set hsr up
>>
>> If the port state is changed after creating the HSR interface, this
>> results in a non-working HSR setup:
>>
>>   ip link add name hsr type hsr slave1 lan1 slave2 lan2 supervision
>> 45 version 1 ip addr add dev hsr 10.0.0.10/24
>>   ip link set lan1 up
>>   ip link set lan2 up
>>   ip link set hsr up
>>
>> In this state, packets will not get forwarded between the HSR ports
>> and communication between HSR nodes that are not direct neighbours in
>> the topology fails.
>>
>> To avoid this, we prevent all forwarding reconfiguration requests for
>> ports that are part of a HSR setup with NETIF_F_HW_HSR_FWD enabled.
>>
>> Fixes: 2d61298fdd7b ("net: dsa: microchip: Enable HSR offloading for
>> KSZ9477") Signed-off-by: Frieder Schrempf
>> <frieder.schrempf@...tron.de> ---
>> I'm posting this as RFC as my knowledge of the driver and the stack in
>> general is very limited. Please review thoroughly and provide
>> feedback. Thanks!
> 
> I don't have the HW at hand at the moment (temporary).
> 
> Could you check if this patch works when you create two hsr interfaces
> - i.e. hsr1 would use HW offloading from KSZ9744 and hsr2 is just the
>   one supporting HSR in software.

My hardware only has three user ports. So that might get a bit difficult
to test. I will try to configure one unconnected port to set up two HSR
links, but I won't be able to fully test this due to the lack of the
fourth physical link.