Am Donnerstag, 16. Januar 2014, 15:39:04 schrieb Florian Weimer: Hi Florian,
>On 01/16/2014 01:57 PM, Dr. Stephen Henson wrote: >> On Thu, Jan 16, 2014, Florian Weimer wrote: >>> The additional resolution of a tick counter might make reseeding >>> after fork unnecessary, but it's difficult to be sure. Something >>> not based on timing information looks desirable to me. >> >> I should point out that the aim of the current code is not to >> completely reseed after fork() but to make the PRNG state diverge so >> that the two processes do not share the same internal PRNG state. > >I get that. I've reconsidered things. Time seems the only thing that >deals with the related VM snapshot issue. > >I still propose to get rid of the time() call (md_rand-time.patch, >AFAICT num == 0 at this point, so I pulled the initialization out of >the loop). OPENSSL_rdtsc() appears to return 0 if the cycle counter >is not available, so md_rand-rtdsc.patch calls it unconditionally if >RDRAND is not available. Isn't the same issue applicable to the FIPS DRNGs? Especially considering that RHEL/Fedora ships these and have them enabled with a kernel command line flag, I am wondering about those. Ciao Stephan ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
