> > It adds some nice
> > performance harming features to the kernel in the process.
>
> No, the last version does not add any overhead.
> Taking into account that linux had bad bug, requiring new lock
> to generate id, it even reduces the overhead.
per CPU ids are simple (just seed with a different secret). Is it worth
it?
>
> Actually, the only alternative is openbsd approach, which really
> adds overhead.
The secure RND can run with a few cache lines, the AVL inetpeer
code needs a potentially unlimited number of cache lines. Given
the current CPU/memory speed ratio, I think the OpenBSD approach
looks much better (my first vote for the per-dst counter was based
on the assumptions that it is free because the routing cache can be
used). Also I think the secure RND is needed anyways to generate
the initial per destination ip counter (so unless you always talk
to the same host the overhead is the same + some ugly code)
For what else would you want to use the inetpeer cache?
The assumption that it can hold information for all peers looks
broken to me. Every attacker can pollute it enough to fill all
available memory (so you only raise the limit over the routing cache
hash a bit, not fix it)
So I think the best solution is to use a reasonably secure RND
that works with minimal state. What do the crypto experts on l-k
recommend?
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/