[U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed

[Josh Wu <josh.wu@atmel.com>]

On 9/16/2015 3:08 PM, Josh Wu wrote:
> Hi, Wolfgang
>
> Thanks for the reply.
>
> On 9/16/2015 2:37 PM, Wolfgang Denk wrote:
>> Dear Josh Wu,
>>
>> In message <1442373526-842-1-git-send-email-josh.wu@atmel.com> you 
>> wrote:
>>> As 'time(0) | getpid()' sometimes get same value. That depends on the
>>> value of getpid().
>> I think removing some "random input" from the way how we compute the
>> seed is a bad idea.
>>
>>> So that is not a expected behavior. We expect different value for the
>>> seed when when run it in many times.
>> What is your execution environment? In any sane OS it is higly
>> unlikely that you will see the same or even similar PIDs for
>> successive runs of the program - each run will start a new process,
>> which will get a new PID.
> my system is Ubuntu 14.04
>
> #uname -a
> Linux melon 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> Following is my test history:
>
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:48:53 CST 2015
> 4a:c3:21:45:17:b2
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:48:56 CST 2015
> a6:29:4b:0b:e6:d0
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:02 CST 2015
> d2:41:66:54:64:aa
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:06 CST 2015
> 2a:58:1d:b0:f0:c5
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:13 CST 2015
> 1e:8e:6f:0e:16:b8
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:19 CST 2015
> 56:4f:58:67:ad:30
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:21 CST 2015
> 2e:53:29:97:6a:8a
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:26 CST 2015
> d2:41:66:54:64:aa
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:35 CST 2015
> d2:41:66:54:64:aa
>
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:50 CST 2015
> 92:33:16:3f:0a:56
> ?  tools  date && ./gen_eth_addr
> Wed Sep 16 14:49:58 CST 2015
> 92:33:16:3f:0a:56
>
> In above commands, I have two duplicated eth addr:
> 92:33:16:3f:0a:56
> d2:41:66:54:64:aa
>
>>
>> [On a mostly idle Linux system (4.1.6 kernel) I see zero dupes in a
>> set of 30,000 invocations of getpid().]
>>
>> One can argue if ORing the values is the most clever idea, or if for
>> example ADDing them would result in more "randomness".
> Sure. The ORing seems has big chance to get same result in my machine.
>
>
>>   But completely
>> removing the pid() is bad - any parallel runs of the program on any
>> machines with synchronized times would predictably result in the same
>> seeds which is definitely worse behaviour than what we have now.
> I understand your concern. My intention is make it harder to generate 
> the duplicated result.
>
> Maybe we can ORing the MSB of time(0)?
> I'll investigate it little more.

I test again, here is a duplicated case:

?  tools  date && ./gen_eth_addr
Wed Sep 16 15:21:30 CST 2015
pid: 0x5aa4, time: 0x55f9187a
86:77:6e:cf:6b:16
?  tools  date && ./gen_eth_addr
Wed Sep 16 15:21:34 CST 2015
pid: 0x5aa6, time: 0x55f9187e
86:77:6e:cf:6b:16

In above both cases, the random seed is same:  (last 4 bits)
   4 | a = e
   6 | e = e

>
>>
>>> So this patch remove the getpid(), just use the time(0) as the seed.
>> NAK.  This is a bad idea.
How about use 'time(0) + (getpid() << 8)'? my reason list in below:
1.  ADD will make the result is more unlikely than OR
2. (<< 8) means larger time difference.

Best Regards,
Josh Wu