Glue: Use /dev/urandom instead of /dev/random

[justuswilhelm]

This will resolve issues with slow random sources (e.g., in virtual machines)

[tbarbette]

Shouldn't we generate randomness completely in userlevel? Seems crazy to rely on read to generate random numbers.

[kohler]

@justuswilhelm: Thanks, great catch.

@tbarbette: Read up on /dev/urandom — it's usually the right answer https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

We should probably have a cryptographic random number generator at userlevel, but for this purpose (initializing the non-cryptographic click_random() generator to a less-than-totally-predictable value) a single read from /dev/urandom is fine.

[justuswilhelm]

@kohler: Thanks so much!

[tbarbette]

@kohler what method would you recommend for this userlevel replacement? Does the following seems good :

We may want a per-cpu seed to avoid false sharing. Or we may want to use a hardware generator (eg. through DPDK support for Intel QuickAssist). So it seems like it should be a user-configurable "method".

• Add a global (uint64_t)user_generator(void thunk); function pointer and a global user_generator_arg void* pointer. (or let them be Router members?)
• When the function is null, follow the normal /dev/urandom path
• To set a specific generator, the user can place a UserCrypto, UserCryptoMP or DPDKCrypto,... element
• Eg : UserCrypto::initialize sets the current seed to click_random() which still uses the default urandom path at that point. And then set the global function to one of its own which return the seed and updates it. After that all calls to click_random rely on that function.

This could also be followed for other features based on system calls, such as the click_jiffies (UserJiffies would rely on a Timer to update a jiffie count).

Advantage is that it is fully configurable, disadvantage is that all Click userlevel configurations would always have the same set of Elements in their config such as UserCryptoMP;UserJiffiesMP;...