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
| ||
|
Date: Sun, 5 Oct 2008 11:06:55 -0700 From: "Andrew Dickinson" <whydna@...dna.net> To: "David Miller" <davem@...emloft.net> Cc: herbert@...dor.apana.org.au, nhorman@...driver.com, netdev@...r.kernel.org, kuznet@....inr.ac.ru, pekkas@...core.fi, jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net Subject: Re: [PATCH] net: implement emergency route cache rebulds when gc_elasticity is exceeded I've got another patch that takes a different approach... Instead of disabling the secret_interval timer or trying to heuristically guess when we're under attack, we continue to invalidate the cache; we just invalidate it with kid-gloves instead of a sledge hammer. Like we do today, we continue to update the genid every time the secret_interval timer expires. Instead of simply creating a new value (and thus invalidating the entire cache), we keep a short history of genid values (I'm thinking on the order of 2-4 previous values). In rt_intern_hash(), when we do the check to see if we already have an existing hash entry, we'll check each of the previous genid versions (hence the desire to keep the history short) before declaring it as not there. If we do find the entry in the hash with an older genid value, we'll re-bucket it into the correct location for the latest genid. Basically, we're allowing entries to continue to exist in the hash after the route cache has been invalidated (they can still be pruned by GC). Happy to send the patch along if you'd like, although I'm not as confident that this approach is really desirable. -A On Sun, Oct 5, 2008 at 10:34 AM, David Miller <davem@...emloft.net> wrote: > From: "Andrew Dickinson" <whydna@...dna.net> > Date: Sat, 4 Oct 2008 21:45:27 -0700 > >> Here's the patch that Herbert's referring to. The basic idea is that >> we have a flag which indicates whether or not we need to invalidate >> the route cache. If any chain exceeds gc_elasticity, we set the flag >> and reschedule the timer. In the worst-case, we'll invalidate the >> route cache once every secret_interval; in the best-case, we never >> invalidate the cache. > > This is a very interesting patch and idea, but... > > Eric showed clearly that on a completely normal well loaded > system, the chain lengths exceed the elasticity all the time > and it's not like these are entries we can get rid of because > their refcounts are all > 1 > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists