From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Wu Date: Wed, 16 Sep 2015 15:27:25 +0800 Subject: [U-Boot] [PATCH] tools: gen_eth_addr: remove getpid() operation for the random seed In-Reply-To: <55F91588.3040305@atmel.com> References: <1442373526-842-1-git-send-email-josh.wu@atmel.com> <20150916063701.44C0C380905@gemini.denx.de> <55F91588.3040305@atmel.com> Message-ID: <55F919DD.2090003@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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