netdev - Re: [RFC PATCH net-next 00/16] bridge: Add MAC Authentication Bypass (MAB) support with offload

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] [day] [month] [year] [list]

Message-ID: <Y2e0zHgzIClULTIB@shredder>
Date:   Sun, 6 Nov 2022 15:21:16 +0200
From:   Ido Schimmel <idosch@...dia.com>
To:     netdev@...io-technology.com
Cc:     netdev@...r.kernel.org, bridge@...ts.linux-foundation.org,
        davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com,
        edumazet@...gle.com, jiri@...dia.com, petrm@...dia.com,
        ivecera@...hat.com, roopa@...dia.com, razor@...ckwall.org,
        vladimir.oltean@....com, mlxsw@...dia.com
Subject: Re: [RFC PATCH net-next 00/16] bridge: Add MAC Authentication Bypass
 (MAB) support with offload

On Sun, Nov 06, 2022 at 01:04:36PM +0100, netdev@...io-technology.com wrote:
> On 2022-10-25 12:00, Ido Schimmel wrote:
> > Merge plan
> > ==========
> > 
> > We need to agree on a merge plan that allows us to start submitting
> > patches for inclusion and finally conclude this work. In my experience,
> > it is best to work in small batches. I therefore propose the following
> > plan:
> > 
> > * Add MAB support in the bridge driver. This corresponds to patches
> >   #1-#2.
> > 
> > * Switchdev extensions for MAB offload together with mlxsw
> >   support. This corresponds to patches #3-#16. I can reduce the number
> >   of patches by splitting out the selftests to a separate submission.
> > 
> > * mv88e6xxx support. I believe the blackhole stuff is an optimization,
> >   so I suggest getting initial MAB offload support without that. Support
> >   for blackhole entries together with offload can be added in a separate
> >   submission.
> 
> As I understand for the mv88e6xxx support, we will be sending
> SWITCHDEV_FDB_ADD_TO_BRIDGE
> events from the driver to the bridge without installing entries in the
> driver.
> Just to note, that will of course imply that the bridge FDB will be out of
> sync with the
> FDB in the driver (ATU).

Stated explicitly here:
https://lore.kernel.org/netdev/20221025100024.1287157-4-idosch@nvidia.com/

Don't see a way around it and it's not critical IMO. The entries will
not appear with the "offload" flag so user space knows they are not in
hardware. Once the "blackhole" flag is supported, user space can replace
such entries and set the "blackhole" flag, which will result in the
entries being programmed to hardware (assuming hardware/driver support).

I plan to submit the offload patches later this week.