[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171116192325.GA16122@lunn.ch>
Date: Thu, 16 Nov 2017 20:23:25 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sarah Newman <srn@...mr.com>
Cc: Willy Tarreau <w@....eu>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
netdev@...r.kernel.org, roopa <roopa@...ulusnetworks.com>
Subject: Re: [PATCH] net: bridge: add max_fdb_count
> Linux bridges can also be used in small embedded devices. With no limit,
> the likely result from those devices being attacked is the device gets
> thrown away for being unreliable.
Hi Sarah
Just to get a gut feeling...
struct net_bridge_fdb_entry is 40 bytes.
My WiFi access point which is also a 5 port bridge, currently has 97MB
free RAM. That is space for about 2.5M FDB entries. So even Roopa's
128K is not really a problem, in terms of memory.
> Maybe what's needed is two thresholds, one for warning and one for enforcement.
> The warning limit would need to be low enough that the information had a good chance
> of being logged before the system was under too much load to be able to convey
> that information. The enforcement limit could be left as default inactive until
> shown that it needed to be otherwise.
What exactly is the problem here? Does the DoS exhaust memory, or does
the hashing algorithm not scale?
It is more work, but the table could be more closely tied to the
memory management code. When memory is getting low, callbacks are made
asking to free up memory. Register such a callback and throw away part
of the table when memory is getting low. There is then no need to
limit the size, but print a rate limited warning when asked to reduce
the size.
Andrew
Powered by blists - more mailing lists