On 16 November 2017 21:23:25 EET, Andrew Lunn <and...@lunn.ch> wrote: >> 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?
Just a note - when net-next opens I'll send patches which move the fdb to a resizeable hashtable that scales nicely even with hundreds of thousands of entries so only the memory issue will remain. > >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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
