[PATCH] getrandom: new applet

Denys Vlasenko vda.linux at googlemail.com
Wed Jul 6 16:39:50 UTC 2016


I think Rob's getting somewhat too agitated here, but his arguments
are convincing.

On Wed, Jul 6, 2016 at 4:33 AM, Rob Landley <rob at landley.net> wrote:
>> Entropy collection is slower on embeded devices, so you have to wait for it, and
>> getrandom() claim to do exactly that
>
> By adding 3 minutes to the boot time?
>
> Look, I'm tired of this. It's not my call if this goes into busybox,
> it's Denysy's. I was just readign to see if it was a thing I should do
> in toybox. But I don't see what the point is of adding it to either
> package. If you want this command it's 5 lines of code and you can
> compile it yourself. I do not see what purpose it serves.
>
> I'm going to start skimming now.
>
>>> What is your use case? Why are you bothering to do this?
>>>
>>> It's entirely possible your new approach is superior, but you have not
>>> successfully articulated _why_ yet. Would you like to try again?
>>
>> Of course :)
>> After heartbleed openbsd people forked openssl in libressl, and
>> started to clean things up,
>> they saw that there was no good way to get entropy in the linux world
>> (file descriptor exhaution)
>
> That's like saying there's no good way to get _input_ in the linux
> world, due to file descriptor exhaustion. No good way to get data from
> disk! No good way to get data from the network! Woe is us! Calamity!
> It's impossible to implement ps because it needs /proc to be mounted!
>
> Seriously?
>
> If your function allocates memory, it should be able to return failure
> if it couldn't. If your function opens a file, it should be able to
> return failure if it couldn't. Why is this a hard concept?

I agree. If the tool wants to be paranoid and it decided that
it absolutely must read /dev/[u]random, then it's completely fine
for this tool to simply fail if it can't do that.


>> Theodore Ts'o while at it added the possibility to block until
>> /dev/urandom as been seeded with 128bits of entropy, specifically
>> targetting embeded systems
>> https://lwn.net/Articles/605828/
>
> Yes, I read it. I am not convinced. I tried it and got almost 3 minutes
> of blocking. (Reading 1 byte from /dev/random with dd gave me 6 minutes
> of blocking, but I suspect the wget initialized the random state a bit.
> Busybox dd was already in the image so I didn't need to wget it...)

getrandom() being faster to unblock than /dev/random indeed feels...
"wrong". I would imagine there should be only one measure
of "cryptographcally secure" in kernel, not two.
When the pool is deemed "cryptographcally securely seeded",
both APIs should unblock. Maybe filing a bug is in order.

Etienne, for now I think the goal you seek can be achieved by blocking on
small read from /dev/random.

You may be able to speed it up
by forking a child which makes system less quiescent.

For example, in the current tree, release_task() -> __exit_signal() ->
-> posix_cpu_timers_exit() ->
-> add_device_randomness((const void*) &tsk->se.sum_exec_runtime,
                                                sizeof(unsigned long long));

Evidently, as of now, task runtime is treated as "somewhat random"
by kernel. While "dd bs=1 count=1 </dev/random >/dev/null" waits,
run a chile which continually forks "sleep 0". This will likely
make dd wake up sooner.


More information about the busybox mailing list