[PATCH] getrandom: new applet

Denys Vlasenko vda.linux at googlemail.com
Mon Jul 11 18:19:29 UTC 2016


On Mon, Jul 11, 2016 at 8:58 AM, Rob Landley <rob at landley.net> wrote:
> On 07/10/2016 01:07 PM, Denys Vlasenko wrote:
>> Yes, blocking for 3 minutes rather than 6 minutes is an improvement,
>> but would 3 minute pause on boot be acceptable for many? I suspect
>> it's still bad; and if I would have that system at hand, I'd experiment
>> with making it initialize random pool faster. Basically,
>> I'd look into kernel source, find what makes it feed entropy pool,
>> and do that activity a lot in a separate process, while dd is blocked.
>
> Unfortunately, you can't just order up more entropy on demand unless you
> have some variant of a hardware random number generator.
>
> Most opportunitites to collect entropy come in spontaneously from the
> outside world, generally when an interrupt provides high precision
> timing information that isn't visible (or predictable) to the outside
> world: the low bits of that data go into the entropy pool. Keyboard
> interrupts, mouse interrupts, and hard drive interrupts are traditional
> randomness sources you can collect timing info from, which the rest of
> the world can't see. Network packets are NOT generally used for this
> because somebody could be listening to your data on the wire and thus
> know exactly when your packets arrive, and reverse engineer those inputs
> to your entropy pool. (They don't have to get it exact, just close
> enough that they can brute force try all the possible inputs to guess
> what your software did with those inputs and thus what keys you generated.)
>
> Alas, things like linksys routers haven't got any of those sources, all
> they've got are network packets and ONE tiny internal source which is
> clock skew between your CPU clock and your PIT, which aren't working
> from the same crystal and those crystals heat up independently so they
> can vary by a few nanoseconds here and there, so you can check the CPU
> cycle counter when the PIT goes off and the clock skew might give you a
> bit or two of actual unpredictability. Maybe. (Of course if you've
> configured your kernel for a tickless system and it's idle, even THAT
> mostly goes away too. Hence the 3 minute wait for this stuff to trickle
> collect 128+ bits.)
>
> Anyway, the point is you can't voluntarily collect _more_ entropy from
> these sources. They run when there's data to gather, calling the
> routines when there isn't new data to gather doesn't help much.


And yet, interestingly, if you try to solve an opposite problem,
the predictable and accurate benchmarking, you suddenly discover that
the damn thing just can't be made to run completely deterministically.

Let's boot in single user, and run just one process, you say.
Let's pin it to CPU0, you say. Switch off all dynamic CPU scaling,
you say. No way. Still not totally deterministic.


I tried timing CPU cycle counter delta across a CPUID(0) instruction.
That alone had some jitter. I collected a few megabytes of it and ran
it through entropy estimator, it said there is ~0.9 bit of randomness per byte.
(I'm not claiming this is true on all CPUs. I'm only sharing my experience
on my CPU).

I tried sending signals to my own process and timing how long does that take.
Also varies.


Back to 3 minute wait. My theory is that an *idle* system
waiting on /dev/random is not the fastest way to collect more entropy.
Make it do something. Make it schedule more and concurrently,
which also will likely make it read timers way more often
than on idle system.
Should not make things worse, as a minimum.


More information about the busybox mailing list