netdev - Re: [PATCH net-next 1/2] bridge: Add a limit on FDB entries

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, 16 May 2023 14:18:15 +0300
From: Nikolay Aleksandrov <razor@...ckwall.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>,
 Oleksij Rempel <linux@...pel-privat.de>,
 Johannes Nixdorf <jnixdorf-oss@....de>, netdev@...r.kernel.org,
 bridge@...ts.linux-foundation.org, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Roopa Prabhu <roopa@...dia.com>,
 Ido Schimmel <idosch@...dia.com>
Subject: Re: [PATCH net-next 1/2] bridge: Add a limit on FDB entries

On 16/05/2023 14:10, Vladimir Oltean wrote:
> On Tue, May 16, 2023 at 02:04:30PM +0300, Nikolay Aleksandrov wrote:
>> That was one of the questions actually. More that I'm thinking about this, the more
>> I want to break it apart by type because we discussed being able to specify a flag
>> mask for the limit (all, dynamic, dynamic+static etc). If we embed these stats into a
>> bridge fdb count attribute, it can be easily extended later if anything new comes along.
>> If switchdev doesn't support some of these global limit configs, we can pass the option
>> and it can deny setting it later. I think this should be more than enough as a first step.
> 
> Ok, and by "type" you actually mean the impossibly hard to understand
> neighbor discovery states used by the bridge UAPI? Like having

Yes, that is what I mean. It's not that hard, we can limit it to a few combinations
that are well understood and defined.

> (overlapping) limits per NUD_REACHABLE, NUD_NOARP etc flags set in
> ndm->ndm_state? Or how should the UAPI look like?

Hmm, perhaps for the time being and for keeping it simpler it'd be best if the type initially is just about
dynamic entries and the count reflects only those. We can add an abstraction later if we want "per-type"/mask limits.
Adding such abstraction should be pretty-straight forward if we keep in mind the flags that can change only
under lock, otherwise proper counting would have to be revisited.