netdev - Re: [PATCH net-next 07/11] vxlan: mdb: Add MDB control path 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ea099909-a205-ed4c-5382-64a01435c23a@blackwall.org>
Date:   Tue, 14 Mar 2023 14:24:29 +0200
From:   Nikolay Aleksandrov <razor@...ckwall.org>
To:     Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org,
        bridge@...ts.linux-foundation.org
Cc:     davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
        edumazet@...gle.com, roopa@...dia.com, petrm@...dia.com,
        mlxsw@...dia.com
Subject: Re: [PATCH net-next 07/11] vxlan: mdb: Add MDB control path support

On 13/03/2023 16:53, Ido Schimmel wrote:
> Implement MDB control path support, enabling the creation, deletion,
> replacement and dumping of MDB entries in a similar fashion to the
> bridge driver. Unlike the bridge driver, each entry stores a list of
> remote VTEPs to which matched packets need to be replicated to and not a
> list of bridge ports.
> 
> The motivating use case is the installation of MDB entries by a user
> space control plane in response to received EVPN routes. As such, only
> allow permanent MDB entries to be installed and do not implement
> snooping functionality, avoiding a lot of unnecessary complexity.
> 
> Since entries can only be modified by user space under RTNL, use RTNL as
> the write lock. Use RCU to ensure that MDB entries and remotes are not
> freed while being accessed from the data path during transmission.
> 
> In terms of uAPI, reuse the existing MDB netlink interface, but add a
> few new attributes to request and response messages:
> 
> * IP address of the destination VXLAN tunnel endpoint where the
>   multicast receivers reside.
> 
> * UDP destination port number to use to connect to the remote VXLAN
>   tunnel endpoint.
> 
> * VXLAN VNI Network Identifier to use to connect to the remote VXLAN
>   tunnel endpoint. Required when Ingress Replication (IR) is used and
>   the remote VTEP is not a member of originating broadcast domain
>   (VLAN/VNI) [1].
> 
> * Source VNI Network Identifier the MDB entry belongs to. Used only when
>   the VXLAN device is in external mode.
> 
> * Interface index of the outgoing interface to reach the remote VXLAN
>   tunnel endpoint. This is required when the underlay destination IP is
>   multicast (P2MP), as the multicast routing tables are not consulted.
> 
> All the new attributes are added under the 'MDBA_SET_ENTRY_ATTRS' nest
> which is strictly validated by the bridge driver, thereby automatically
> rejecting the new attributes.
> 
> [1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-3.2.2
> 
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
> 
> Notes:
>     v1:
>     * Remove restrictions regarding mixing of multicast and unicast remote
>       destination IPs in an MDB entry. While such configuration does not
>       make sense to me, it is no forbidden by the VXLAN FDB code and does
>       not crash the kernel.
>     * Fix check regarding all-zeros MDB entry and source.
> 
>  drivers/net/vxlan/Makefile        |    2 +-
>  drivers/net/vxlan/vxlan_core.c    |    8 +
>  drivers/net/vxlan/vxlan_mdb.c     | 1341 +++++++++++++++++++++++++++++
>  drivers/net/vxlan/vxlan_private.h |   31 +
>  include/net/vxlan.h               |    5 +
>  include/uapi/linux/if_bridge.h    |   10 +
>  6 files changed, 1396 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/net/vxlan/vxlan_mdb.c


Reviewed-by: Nikolay Aleksandrov <razor@...ckwall.org>