[Development] QRandomGenerator and boot times

Thiago Macieira thiago.macieira at intel.com
Thu Sep 14 17:01:42 CEST 2017


On Thursday, 14 September 2017 00:21:45 PDT Sami Nurmenniemi wrote:
> Hi,
> 
> Commit 120ecc976fc3d5504d234702f68c2ad3898b77a4 changes default behavior of
> QRandomGenerator to use getentropy instead of /dev/urandom. This causes
> problems for device boot times when using QRandomGenerator in the boot
> sequence. As the commit message itself states "What's more, the glibc
> implementation blocks until entropy is available on early boot". Depending
> on the hw + kernel configuration of the device, this can increase boot time
> by more than a minute. For example in the Boot2Qt image qdbd and qtlauncher
> demo now block until the nonblocking pool is initialized. See QTBUG-63188.
> 
> What do you suggest for working around this problem?
> 1. Disable feature "getentropy" from Boot2Qt builds
> - This is the behavior in Qt < 5.10.x
> - Only difference in the entropy of randomness is in the early boot

How does that help? getentropy(3) is implemented using getrandom(2), which 
reads from the same source as /dev/urandom. The difference is that 
getrandom(2) blocks until entropy is available, instead of just returning an 
error.

Your problem is lack of entropy. Please feed entropy to the kernel or accept 
the block.

> 2. Add "rng-tools" to the image for inputting entropy to the kernel
> - Speeds up initialization of nonblocking pool
> - On devices with HW random generator, this adds real entropy to the kernel
> pool - On devices without HW random generator, this adds bad entropy from
> /dev/urandom to the kernel pool 

Huh? Adding entropy from /dev/urandom back to /dev/urandom? This is worse than 
the "rob Peter to pay Paul" - you want to rob Peter to pay Peter.

Also, why does your device have a HWRNG that the kernel is not using? 
Shouldn't the kernel use it to feed entropy?

In any case, saving entropy across boots and re-feeding it to the kenrel is a 
good idea.

> 3. Setting  QT_HASH_SEED for the affected
> processes
> - Not a good solution IMO
> - It seems code using this in qhash.cpp is the actual reason for the blocked
> processes (originated from QDebug) 

Changing the seed is not a good idea. But you can delay the using of QHash, by 
removing that QDebug use. It may not get you very far though.

> 4. Something else?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list