[PATCH] getrandom: new applet

[Etienne Champetier]

I just sent a long answer to Rob (with a sum up at the beginning)


2016-07-06 18:39 GMT+02:00 Denys Vlasenko <vda.linux at googlemail.com>:
> 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.

Not a bug, it's how it's designed, see my answer to Rob, 2 pools,
/dev/urandom pool is seeded before /dev/random pool
(there is also a 3rd pool, the input pool)

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

take 2 times more to unblock, and might block again

>
> 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.

My applet is only 207K, and if i'm doing C, i will use getrandom()

Regards
Etienne