From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E78BD40543 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2F91B40534 MIME-Version: 1.0 Date: Sun, 28 Aug 2022 14:00:29 +0200 From: netdev@kapio-technology.com In-Reply-To: References: <20220826114538.705433-1-netdev@kapio-technology.com> <20220826114538.705433-7-netdev@kapio-technology.com> Message-ID: <7654860e4d7d43c15d482c6caeb6a773@kapio-technology.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH v5 net-next 6/6] selftests: forwarding: add test of MAC-Auth Bypass to locked port tests List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ido Schimmel Cc: Andrew Lunn , Alexandre Belloni , Nikolay Aleksandrov , Kurt Kanzenbach , Eric Dumazet , linux-kselftest@vger.kernel.org, Shuah Khan , Ivan Vecera , Florian Fainelli , Daniel Borkmann , bridge@lists.linux-foundation.org, linux-arm-kernel@lists.infradead.org, Roopa Prabhu , kuba@kernel.org, Paolo Abeni , Vivien Didelot , Woojung Huh , Landen Chao , Jiri Pirko , Christian Marangi , Hauke Mehrtens , Sean Wang , DENG Qingfang , Claudiu Manoil , linux-mediatek@lists.infradead.org, Matthias Brugger , Yuwei Wang , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com, Vladimir Oltean , davem@davemloft.net On 2022-08-27 20:21, Ido Schimmel wrote: > On Fri, Aug 26, 2022 at 01:45:38PM +0200, Hans Schultz wrote: >> +locked_port_mab() >> +{ >> + RET=0 >> + check_locked_port_support || return 0 >> + >> + ping_do $h1 192.0.2.2 >> + check_err $? "MAB: Ping did not work before locking port" >> + >> + bridge link set dev $swp1 locked on >> + bridge link set dev $swp1 learning on > > "locked on learning on" is counter intuitive and IMO very much a > misconfiguration that we should have disallowed when the "locked" > option > was introduced. It is my understanding that the only reason we are even > talking about it is because mv88e6xxx needs it for MAB for some reason. As the way mv88e6xxx implements "learning off" is to remove port association for ingress packets on a port, but that breaks many other things such as refreshing ATU entries and violation interrupts, so it is needed and the question is then what is the worst to have 'learning on' on a locked port or to have the locked port enabling learning in the driver silently? Opinions seem to differ. Note that even on locked ports without MAB, port association on ingress is still needed in future as I have a dynamic ATU patch set coming, that uses age out violation and hardware refreshing to let the hardware keep the dynamic entries as long as the authorized station is sending, but will age the entry out if the station keeps silent for the ageing time. But that patch set is dependent on this patch set, and I don't think I can send it before this is accepted... > Please avoid leaking this implementation detail to user space and > instead use the "MAB" flag to enable learning if you need it in > mv88e6xxx. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2DE2C0502A for ; Sun, 28 Aug 2022 12:00:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229785AbiH1MAj (ORCPT ); Sun, 28 Aug 2022 08:00:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229821AbiH1MAe (ORCPT ); Sun, 28 Aug 2022 08:00:34 -0400 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0FF4F18B31; Sun, 28 Aug 2022 05:00:31 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 829B718845C3; Sun, 28 Aug 2022 12:00:29 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 797F325032B7; Sun, 28 Aug 2022 12:00:29 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 6C87D9EC0008; Sun, 28 Aug 2022 12:00:29 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Sun, 28 Aug 2022 14:00:29 +0200 From: netdev@kapio-technology.com To: Ido Schimmel Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , UNGLinuxDriver@microchip.com, Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , Claudiu Manoil , Alexandre Belloni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Christian Marangi , Daniel Borkmann , Yuwei Wang , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 net-next 6/6] selftests: forwarding: add test of MAC-Auth Bypass to locked port tests In-Reply-To: References: <20220826114538.705433-1-netdev@kapio-technology.com> <20220826114538.705433-7-netdev@kapio-technology.com> User-Agent: Gigahost Webmail Message-ID: <7654860e4d7d43c15d482c6caeb6a773@kapio-technology.com> X-Sender: netdev@kapio-technology.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On 2022-08-27 20:21, Ido Schimmel wrote: > On Fri, Aug 26, 2022 at 01:45:38PM +0200, Hans Schultz wrote: >> +locked_port_mab() >> +{ >> + RET=0 >> + check_locked_port_support || return 0 >> + >> + ping_do $h1 192.0.2.2 >> + check_err $? "MAB: Ping did not work before locking port" >> + >> + bridge link set dev $swp1 locked on >> + bridge link set dev $swp1 learning on > > "locked on learning on" is counter intuitive and IMO very much a > misconfiguration that we should have disallowed when the "locked" > option > was introduced. It is my understanding that the only reason we are even > talking about it is because mv88e6xxx needs it for MAB for some reason. As the way mv88e6xxx implements "learning off" is to remove port association for ingress packets on a port, but that breaks many other things such as refreshing ATU entries and violation interrupts, so it is needed and the question is then what is the worst to have 'learning on' on a locked port or to have the locked port enabling learning in the driver silently? Opinions seem to differ. Note that even on locked ports without MAB, port association on ingress is still needed in future as I have a dynamic ATU patch set coming, that uses age out violation and hardware refreshing to let the hardware keep the dynamic entries as long as the authorized station is sending, but will age the entry out if the station keeps silent for the ageing time. But that patch set is dependent on this patch set, and I don't think I can send it before this is accepted... > Please avoid leaking this implementation detail to user space and > instead use the "MAB" flag to enable learning if you need it in > mv88e6xxx. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4AE67ECAAD2 for ; Sun, 28 Aug 2022 12:01:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bQ8i4YBuIxBYAxaP5VE1orLpmvXToJ0kjdP355zLcws=; b=yqakRoBbR1fmecGTcEhRbJO+UA G33eene5/S0YobypD5cafOOt+eDUYhUVcyctHec2I0YYcenP/J1SCC9tQFQ2+y4SfN6QY0VZw0ERr sm3C+rPC6eBmOKzPxmgOCN+c2l5J0Jjz/F0zTU4YXuXAJENRyG4RTtRmubXEvjHGKBDGxovZ/C+df DT7zmBgccP9yz5aLL43ZCl8fQqewmR+P7HwU/STbpnxyxrkzjTVgrEn2dULQ/MBLeWg3QEDH2Do5k v4IBNfxYMgztOXf1r6sZMGibHEQSAcu5wIyDeP6hUanje5cEoPbPCwwqgG9e5gd6UZ3aLWTIJk6TA b16MBImw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oSGxu-00GdEN-O4; Sun, 28 Aug 2022 12:00:34 +0000 Received: from mailout-taastrup.gigahost.dk ([46.183.139.199]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oSGxr-00GdD9-9S; Sun, 28 Aug 2022 12:00:33 +0000 Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 829B718845C3; Sun, 28 Aug 2022 12:00:29 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 797F325032B7; Sun, 28 Aug 2022 12:00:29 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 6C87D9EC0008; Sun, 28 Aug 2022 12:00:29 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Sun, 28 Aug 2022 14:00:29 +0200 From: netdev@kapio-technology.com To: Ido Schimmel Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Florian Fainelli , Andrew Lunn , Vivien Didelot , Vladimir Oltean , Eric Dumazet , Paolo Abeni , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , UNGLinuxDriver@microchip.com, Sean Wang , Landen Chao , DENG Qingfang , Matthias Brugger , Claudiu Manoil , Alexandre Belloni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Christian Marangi , Daniel Borkmann , Yuwei Wang , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, bridge@lists.linux-foundation.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 net-next 6/6] selftests: forwarding: add test of MAC-Auth Bypass to locked port tests In-Reply-To: References: <20220826114538.705433-1-netdev@kapio-technology.com> <20220826114538.705433-7-netdev@kapio-technology.com> User-Agent: Gigahost Webmail Message-ID: <7654860e4d7d43c15d482c6caeb6a773@kapio-technology.com> X-Sender: netdev@kapio-technology.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220828_050032_220077_915C52AD X-CRM114-Status: GOOD ( 17.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-08-27 20:21, Ido Schimmel wrote: > On Fri, Aug 26, 2022 at 01:45:38PM +0200, Hans Schultz wrote: >> +locked_port_mab() >> +{ >> + RET=0 >> + check_locked_port_support || return 0 >> + >> + ping_do $h1 192.0.2.2 >> + check_err $? "MAB: Ping did not work before locking port" >> + >> + bridge link set dev $swp1 locked on >> + bridge link set dev $swp1 learning on > > "locked on learning on" is counter intuitive and IMO very much a > misconfiguration that we should have disallowed when the "locked" > option > was introduced. It is my understanding that the only reason we are even > talking about it is because mv88e6xxx needs it for MAB for some reason. As the way mv88e6xxx implements "learning off" is to remove port association for ingress packets on a port, but that breaks many other things such as refreshing ATU entries and violation interrupts, so it is needed and the question is then what is the worst to have 'learning on' on a locked port or to have the locked port enabling learning in the driver silently? Opinions seem to differ. Note that even on locked ports without MAB, port association on ingress is still needed in future as I have a dynamic ATU patch set coming, that uses age out violation and hardware refreshing to let the hardware keep the dynamic entries as long as the authorized station is sending, but will age the entry out if the station keeps silent for the ageing time. But that patch set is dependent on this patch set, and I don't think I can send it before this is accepted... > Please avoid leaking this implementation detail to user space and > instead use the "MAB" flag to enable learning if you need it in > mv88e6xxx. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel