"Andi Kleen" ([EMAIL PROTECTED]) wrote:
To truly defend against this you would likely need a cryptographic hash, which would be likely too slow.
I do not think that a cryptographically secure hash is necessary for this. Using a better hash function (i.e. one which does a good job of throroughly mixing the input bits, as jenkins does), is sufficient when combined with a secret per-boot salt, something which is easily demonstrable by test runs.
If it's a real problem the better fix would be to switch to some kind of balanced tree (like Evgeniy is proposing) .
I don't have any special attachment to the Jenkins hash, or to a hash table even. So, _yes_, by all means if a better solution is available let us use it and I'll be the first to cheer. But I don't know if Evgeniy's work is ready for prime time, and I consider plugging in an improved hash function to be an acceptable solution in the meantime.
But I think it can be mostly ignored.
With all due respect, it cannot. An attacker with a small-sized botnet (which is ~250 hosts) can create chains that contain well in excess of 3000 items. A big botnet (and there exist botnets with well over 5000 machines in them) can bring a system to its knees. You may not have gotten bitten by this, but others, including myself and Eric Dumazet have. And I believe that David Miller agrees, although I do not want to put words in his mouth -- or his keyboard, as the case may be.
What this boils down to is, yes, we can keep patching our own kernels to use tagged jenkins hashing if this affects us, waiting for something better to come along. But isn't it more reasonable to add this into the kernel, at least as a non-default compile time option, and allow administrators to decide whether this is something they want to use?
-n - 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
