Re: Question on random.c add_interrupt_randomness function

2018-04-24 Thread Theodore Y. Ts'o
On Tue, Apr 24, 2018 at 03:24:55PM +0200, Harald Freudenberger wrote:
> The condition is true and terminates the function
> when the count value of the cpu fast pool is below 64
> AND the time since last mix of the pool is lower than
> HZ (so lower than 1s).
> This means the code following this condition is runu
> when the count value is > 64 or the last mix is more
> than 1s old.
> As the fast_mix() function does a fast_pool->count++
> effectively every 64 invocations this condition is
> false and the rest of the function is executed.
> 
> Is this the intention?

Yes, that's the intention.  Originally we required sampling the IP
and/or architecture's cycle counter (if available) and mixing it using
fast_mix before we transfer it to the input_pool and credit it with a
bit of entropy.

The problem is that on some architectures interrupts happen are much
less frequently.  So what we did is to assume that one second's worth
of interrupts will be sufficient to derive a single bit of entropy.

   - Ted


Question on random.c add_interrupt_randomness function

2018-04-24 Thread Harald Freudenberger
Hello Theodore,
I am currently investigating a better implementation of
the arch_get_random_long_seed() implementation for s390.
And so I stumbled over the function add_interrupt_randomness()
in random.c and have one question regarding this code:

void add_interrupt_randomness(int irq, int irq_flags)
{
    ...
    fast_mix(fast_pool);
    ...
    if ((fast_pool->count < 64) &&
        !time_after(now, fast_pool->last + HZ))
        return;
    ...
}

The condition is true and terminates the function
when the count value of the cpu fast pool is below 64
AND the time since last mix of the pool is lower than
HZ (so lower than 1s).
This means the code following this condition is run
when the count value is > 64 or the last mix is more
than 1s old.
As the fast_mix() function does a fast_pool->count++
effectively every 64 invocations this condition is
false and the rest of the function is executed.

Is this the intention? Shouldn't the condition
terminate the function either when there are fewer
than 64 mixes in the pool OR time since last
invocation is < 1 s ?

regards
Harald Freudenberger