netdev - Re: [PATCH net-next 11/15] mlxsw: spectrum_switchdev: Add locked bridge port support

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: <20221108145929.qmu2gvd5vvgvasyy@skbuf>
Date:   Tue, 8 Nov 2022 16:59:29 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Petr Machata <petrm@...dia.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Ivan Vecera <ivecera@...hat.com>, netdev@...r.kernel.org,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Roopa Prabhu <roopa@...dia.com>, Jiri Pirko <jiri@...dia.com>,
        bridge@...ts.linux-foundation.org,
        Ido Schimmel <idosch@...dia.com>,
        "Hans J . Schultz" <netdev@...io-technology.com>, mlxsw@...dia.com
Subject: Re: [PATCH net-next 11/15] mlxsw: spectrum_switchdev: Add locked
 bridge port support

On Tue, Nov 08, 2022 at 11:47:17AM +0100, Petr Machata wrote:
> From: Ido Schimmel <idosch@...dia.com>
> 
> 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 <idosch@...dia.com>
> Reviewed-by: Petr Machata <petrm@...dia.com>
> Signed-off-by: Petr Machata <petrm@...dia.com>
> ---

Can't really figure out from the patch, sorry. Port security works with
LAG offload?