Re: [PATCH 4/6] Do not use HP_TIMING_NOW for random bits

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 13/02/2019 11:57, Wilco Dijkstra wrote:
> Hi Adhemerval,
> 
> This looks good. One comment though:
> 
> +/* Provides fast pseudo-random bits through clock_gettime.  It has unspecified
> +   starting time, nano-second accuracy, its randomness is significantly better
> +   than gettimeofday, and for mostly architectures it is implemented through
> +   vDSO instead of a syscall.  */
> +static inline uint64_t
> +random_bits (void)
> +{
> +  struct timespec tv;
> +  __clock_gettime (CLOCK_MONOTONIC, &tv);
> +  return tv.tv_nsec + UINT64_C(1000000000) * tv.tv_sec;
> +}
> 
> It might be better to just return 32 bits given the top bits are going to be mostly
> identical. Also it makes sense to shuffle the bits slightly given most code relies
> on the low bits being the most random, but if the increment is a multiple of a ns
> the low bits may never change. Something like:
> 
> tmp = tv.tv_nsec ^ tv.tv_sec;
> tmp ^= (tmp << 24) | (tmp >> 8);
> 
> Wilco
> 

Currently __gen_tempname still requires at least 48 bits to generate the random
number, so I think returning 64 bits is still preferable.  I think we can add
a comment that the 32 upper bits will show less entropy, what I am not sure is if
we should add some shuffling to upper bits as well or just document the shuffling
in lower bits.