netdev - Re: [RFC net-next 2/7] net: bridge: switchdev: Include local flag in FDB notifications

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]

Date:   Tue, 19 Jan 2021 02:42:00 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Nikolay Aleksandrov <nikolay@...dia.com>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>, davem@...emloft.net,
        kuba@...nel.org, andrew@...n.ch, vivien.didelot@...il.com,
        f.fainelli@...il.com, roopa@...dia.com, netdev@...r.kernel.org,
        jiri@...nulli.us, idosch@...sch.org, stephen@...workplumber.org
Subject: Re: [RFC net-next 2/7] net: bridge: switchdev: Include local flag in
 FDB notifications

On Tue, Jan 19, 2021 at 12:42:04AM +0200, Nikolay Aleksandrov wrote:
> No, it shouldn't be a problem to change that. We should be careful about the
> way it's changed though because reporting it for all ports might become a scale
> issue with 4k vlans, and also today you can't add the same mac for multiple ports.
> Perhaps the best way is to report it for the bridge itself, while still allowing
> such entries to be added/deleted by user-space.

I think what Tobias is trying to achieve is:
(a) offload the locally terminated FDB addresses through switchdev, in a
    way that is not "poisoned", i.e. the driver should not be forced to
    recognize these entries based on the is_local flag. This includes
    the ports MAC addresses which are currently notified as is_local and
    with fdb->dst = source brport (not NULL).
(b) remain compatible with the mistakes of the past, i.e. DSA and
    probably other switchdev users will have to remain oblivious of the
    is_local flag. So we will still have to accept "bridge fdb add
    00:01:02:03:04:05 dev swp0 master local", and it will have to keep
    incorrectly installing a front-facing static FDB entry on swp0
    instead of a local/permanent one.

In terms of implementation, this would mean that for added_by_user
entries, we keep the existing notifications broken as they are.
Whereas for !added_by_user, we replace them as much as possible with
"fdb->dst == NULL" entries (i.e. for br0).

I haven't looked closely at the code, and I hope that this will not
happen, but maybe some of these addresses will inevitably have to be
duplicated with is_local addresses that were previously notified. In
that case I'm thinking there must be some hackery to always offload the
addresses in this order: first the is_local address, then the br0
address, to allow the bad entry to be overwritten with the good one.

Finally, we should modify the bridge manpage to say "we know that the
local|permanent flag is added by default, but it's deprecated so pls
don't use it anymore, just use fdb on br0".

How does this sound?