Stephen Hemminger [off-list ref] writes:
On Fri, 28 Jan 2005 12:45:17 -0800
"David S. Miller" [off-list ref] wrote:
quoted
On Fri, 28 Jan 2005 21:34:52 +0100
Lorenzo Hernández García-Hierro [off-list ref] wrote:
quoted
Attached the new patch following Arjan's recommendations.
No SMP protection on the SBOX, better look into that.
The locking you'll likely need to add will make this
routine serialize many networking operations which is
one thing we've been trying to avoid.
per-cpu would be the way to go here.
I don't think so no - just doing per cpu counters you
risk nearby duplicates, which can cause even easier data corruption
(e.g. during ip fragment reassembly - it is already very weak
and making it weaker is probably not a good idea)
If you want SMP performance for ipids you can resurrect
the old "cookie jar" approach I used in 2.4 time frame to get
rid of inetpeers. The idea was that you have global state,
and each CPU would regenerate some numbers from the state,
then store them in a private "jar" and use them use, then
look at the global state with locking again etc.
This can be tuned on how big the jar is - the bigger the
smaller the sequence space (risky for 16bit ipids), but
the better the scalability.
But before doing anything like this I would recommend
that someone skilled in cryptography evaluates the security
of these functions carefully and see if it actually has any
advantages. I remember that Andrey S. broke
some of the "cool" "secure" openbsd IDs easily some years ago.
At least for ipids I'm utterly sceptical. 16bits are just
hopeless.
-Andi