From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 31 Jul 2005 00:15:58 +1000
> Unfortunately, leaving ipc entires around opens us to > a potential DoS attack. By spoofing source addresses the attacker > could fill up our memory with these ipc entries. Granted we could > prune them in ip_evictor. However, that does add significant > complexity. > > So overall I'd say that the kmalloc cost is small enough that this > isn't worth it. This patch looks more complicated than it probably should be, you agree with me and perhaps I'm not looking at the patch from the right angle anyways :) One comment on this reusage idea. I think this can be implemented simply. When a refcount drops to zero, just keep it in the hash table. Then, on lookup of an ipc you do the following: 1) search for matching entry, if we find matching entry with zero refcount, we reuse and everything is perfect 2) if we find no matching entry, reuse any zero refcount entry we spotted during the search 3) else, if no matching entry and no zero refcount entries, allocate and insert a new one This bounds the pollution a remote entity could cause to the number of hash chains we have, and no greater. I wish I could come up with a sane way to use the inetpeer cache to store this info. Unfortunately we need to key on address _and_ ID. What's more, even if inetpeer could be made to work we would need to think about inetpeer cache pollution issues similar to the ipc ones we are trying to discuss here. I actually think inetpeer would be ok in this regard due to it's "unused list" scheme, but we'd need to double- check just to make sure. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
