Re: [PATCH] net: implement emergency route cache rebulds when gc_elasticity is exceeded
From: David Miller <davem@davemloft.net>
Date: 2008-09-30 14:08:15
From: Neil Horman <nhorman@tuxdriver.com> Date: Mon, 29 Sep 2008 15:12:54 -0400
We currently have the ability to disable our route cache secret interval rebuild timer (by setting it to zero), but if we do that its possible for an attacker (if they guess our route cache hash secret, to fill our system with routes that all hash to the same bucket, destroying our performance. This patch provides a backstop for that issues. In the event that our rebuild interval is disabled (or very large), if any hash chain exceeds ip_rt_gc_elasticity, we do an emergency hash rebuild. During the hash rebuild we: 1) warn the user of the emergency 2) disable the rebuild timer 3) invalidate the route caches 4) re-enable the rebuild timer with its old value
I just want to clarify what my intentions were when I spoke with Neil about this stuff last week. The idea is that we can by default not rebuild the secret at all. And only when we notice that chains are growing larger than "(NUM_RTCACHE_ENTRIES / NUM_HASH_CHAINS) * N", only then do we do this secret rebuild and flush. Where N is some constant of configurable value, the GC elasticity is some example. Normally this whole hash secret business is totally unnecessary and there is zero reason to do it until we notice there is actually some kind of deep hash chain growth problem. It's expensive, we flush the whole routing cache, so doing it every so often by default makes no sense and it is causing performance problems for people.