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 69C85C433FE for ; Tue, 8 Nov 2022 14:59:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233904AbiKHO7g (ORCPT ); Tue, 8 Nov 2022 09:59:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233500AbiKHO7e (ORCPT ); Tue, 8 Nov 2022 09:59:34 -0500 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA562450BF for ; Tue, 8 Nov 2022 06:59:33 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id n12so39229713eja.11 for ; Tue, 08 Nov 2022 06:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=J1AA1jk+noLUWn3EI/QqWPmqga5tVeAmuKcLyOASUC4=; b=IEWU2L7UG31b+6vQvoFxaCyrT42BgWijq9qxlw0Uf/9Ba6xAlk4Bxgxca1Xcm8Ccuo 7F2ubojIxKLT/0z31+7rEioqCjL2UD9+Azteadg8f1HjRQszJBAlfPRNF/VxTvrN968B 8vxl69gCu+f5oUJixPF3rpKhITtTFXqZwNMrAEfwFyB/ytzWO4PWvIrOmRxjvOwWnjYY h8Q+OBg2avLxlA/HgFl/re7DwIg27wrbAK8tPaR8IidURoG0tL4XgJApZjlB1wM+hetX bys9z9qYflR+sGikSVfflk4z4VeNvof2IvEc1wU7JbruXt0fpmk4hHpk/3HHTCmdPVNY kYXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=J1AA1jk+noLUWn3EI/QqWPmqga5tVeAmuKcLyOASUC4=; b=ke2QUix8CcljXB0H68l6p9oDES4xQvDa/6TiW04vJPfNlqbc879qX4qqab0LwLyJEm dIM60rjYGnROVfsy/tfr3Od3cPyP9yWumUYCg48QLpuqfwVSURGL+9d0sNekph2gmmWb Sg1fz4Im8VC2/t4Q4SvxlCRZN4W6tm2ESOS3jIPTW8vseXKAlOP0cY+ahqVeXSEurnqw txEEY9BSubolxa5s0Sqz9B1UQjp3WFuYYLRHZ/2teCXFJixtWQmMo0Udj6GyHfmefncw ini+iNJB+1EUcieK4mRycFjJrx/JGw+bZFOneJDiJ++JI3tRtMfH00jlip4bhzrbkTKe Pzkg== X-Gm-Message-State: ACrzQf1qeXPanDH1FpRhiGCUcEczkqTU7vKINJxTLqbSwW2g/zSyQrzU fqVrpZ5M1h+8J3nYBG9CT/A= X-Google-Smtp-Source: AMsMyM4Ljx+XXPIpKL7Id2vhWE+Fe3vEdcs7aRwa8g0SxxBXGIvy+66vnuylYE+kk5j8vNM0v1qXzw== X-Received: by 2002:a17:906:8a54:b0:7ad:e517:1eb with SMTP id gx20-20020a1709068a5400b007ade51701ebmr40139744ejc.567.1667919572404; Tue, 08 Nov 2022 06:59:32 -0800 (PST) Received: from skbuf ([188.27.184.197]) by smtp.gmail.com with ESMTPSA id fy8-20020a170906b7c800b007877ad05b32sm4794721ejb.208.2022.11.08.06.59.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Nov 2022 06:59:31 -0800 (PST) Date: Tue, 8 Nov 2022 16:59:29 +0200 From: Vladimir Oltean To: Petr Machata Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Ivan Vecera , netdev@vger.kernel.org, Nikolay Aleksandrov , Roopa Prabhu , Jiri Pirko , bridge@lists.linux-foundation.org, Ido Schimmel , "Hans J . Schultz" , mlxsw@nvidia.com Subject: Re: [PATCH net-next 11/15] mlxsw: spectrum_switchdev: Add locked bridge port support Message-ID: <20221108145929.qmu2gvd5vvgvasyy@skbuf> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Nov 08, 2022 at 11:47:17AM +0100, Petr Machata wrote: > From: Ido Schimmel > > Add locked bridge port support by reacting to changes in the > 'BR_PORT_LOCKED' flag. When set, enable security checks on the local > port via the previously added SPFSR register. > > When security checks are enabled, an incoming packet will trigger an FDB > lookup with the packet's source MAC and the FID it was classified to. If > an FDB entry was not found or was found to be pointing to a different > port, the packet will be dropped. Such packets increment the > "discard_ingress_general" ethtool counter. For added visibility, user > space can trap such packets to the CPU by enabling the "locked_port" > trap. Example: > > # devlink trap set pci/0000:06:00.0 trap locked_port action trap Got the answer I was looking for. > > Unlike other configurations done via bridge port flags (e.g., learning, > flooding), security checks are enabled in the device on a per-port basis > and not on a per-{port, VLAN} basis. As such, scenarios where user space > can configure different locking settings for different VLANs configured > on a port need to be vetoed. To that end, veto the following scenarios: > > 1. Locking is set on a bridge port that is a VLAN upper > > 2. Locking is set on a bridge port that has VLAN uppers > > 3. VLAN upper is configured on a locked bridge port > > Examples: > > # bridge link set dev swp1.10 locked on > Error: mlxsw_spectrum: Locked flag cannot be set on a VLAN upper. > > # ip link add link swp1 name swp1.10 type vlan id 10 > # bridge link set dev swp1 locked on > Error: mlxsw_spectrum: Locked flag cannot be set on a bridge port that has VLAN uppers. > > # bridge link set dev swp1 locked on > # ip link add link swp1 name swp1.10 type vlan id 10 > Error: mlxsw_spectrum: VLAN uppers are not supported on a locked port. > > Signed-off-by: Ido Schimmel > Reviewed-by: Petr Machata > Signed-off-by: Petr Machata > --- Can't really figure out from the patch, sorry. Port security works with LAG offload?