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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B2A3B3B.3000308@gmail.com>
Date:	Thu, 17 Dec 2009 15:07:55 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Lucian Adrian Grijincu <lgrijincu@...acom.com>
CC:	netdev@...r.kernel.org, Octavian Purdila <opurdila@...acom.com>
Subject: Re: [RFC 1/2] udp: add non-linear uniform port allocation scheme
 option /proc/sys/net/ipv4/udp_port_randomization

Le 16/12/2009 20:24, Lucian Adrian Grijincu a écrit :
> 
> When we allocate ports with a (really) high frequency, randomization
> does more harm as some values tend to repeat with a higher frequency
> than they would if allocated uniformly, while others are selected more
> rarely.
> 
> This patch does not allocate ports linearly as older kernels used to do,
> but it allocates the port with an uniform frequency.
> 
> For example: assuming UDP_HTABLE_SIZE=8, hint=3, low=0, high=32
> This leads to:
>> first=3, last=3+8=11, rand=(1 | 1) * UDP_HTABLE_SIZE=8
> 
> The port selection code is similar to:
>> for first in [3..11):
>>     snum = first
>>     do if (!good(snum)) snum+=8 while(snum!=first)
> 
> Will give the following sequence for snum (skipping `modulo 32` for
> brevity)
>   3,  3+8,  3+8+8,  3+8+8+8,
>   4,  4+8,  4+8+8,  4+8+8+8,
>  ...
>   9,  9+8,  9+8+8,  9+8+8+8,
>  10, 10+8, 10+8+8, 10+8+8+8,
> 
> This will generate all numbers in the [low..high) interval with the
> same frequency. This leads to better performance when most ports are
> already allocated.
> 
> Randomization is still enabled by default for normal setups that will
> most likely not encounter such situations.
> 

I dont like this patch, I am not convinced at all by your example.

Your example is flawed, since UDP_HTABLE_SIZE >= 128 (128 is the minimum hash size)

I cannot understand why chosing a "one" increment instead of a "random odd" increment
can give a more uniform allocation frequency.

If port randomization is not good enough, please make it better, not reverting to
plain sequential old behavior... (your application can do its own port allocation by the way)

BTW, net-next-2.6 is not yet open, this is not the right time to submit non bug fixes patches.

Thanks
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ