VirtIO RNG and unexpected behavior of arc4random_buf() standard function of C

[shengwen-tw]

This issue was identified during the development of #34 , where kmscube was found to have an extremely high chance of hanging during startup.

Upon investigation, I discovered that the reason kmscube hangs is due to the use of arc4random_buf(), a standard C library function. Since Buildroot packages are mostly built from source, I was able to trace the issue directly to its source.

Firstly, kmscube has the following package dependencies:
kmscube -> Mesa3D -> libgbm (Generic Buffer Management) -> libexpat (an XML parser)

During its startup, kmscube calls a libgbm function that reads application and driver settings from 00-mesa-defaults.conf. This process involves libexpat to parse XML syntax.

It turns out that during initialization, the parser calculates a salt hash, which requires using arc4random_buf() to generate a random number. However, due to an unknown issue, arc4random_buf() often hangs, preventing kmscube from starting.

Currently, we can work around the issue by modifying the following file:

buildroot/output/build/expat-2.6.2/lib/xmlparse.c

static unsigned long
generate_hash_secret_salt(XML_Parser parser) {
+ return 2147483647;

  unsigned long entropy;
  (void)parser;

  /* "Failproof" high quality providers: */
#if defined(HAVE_ARC4RANDOM_BUF)
  arc4random_buf(&entropy, sizeof(entropy));
  return ENTROPY_DEBUG("arc4random_buf", entropy);
#elif defined(HAVE_ARC4RANDOM)
  ...
}

It's unclear if this issue is related to #67, but we may need to further investigate the random number generation within the emulated environment.

[shengwen-tw]

Quoted from https://en.wikipedia.org/wiki//dev/random:

/dev/random typically blocked if there was less entropy available than requested; more recently (see below for the differences between operating systems) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently. The /dev/urandom device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot. Not all operating systems implement the same methods for /dev/random and /dev/urandom.

Entropy injection (VirtIO RNG)

With Linux kernel 3.16 and newer,[12] the kernel itself mixes data from hardware random number generators into /dev/random on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as rngd from rng-tools, is needed to do that job. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0,[13] and as such, is currently the only HWRNG mixed into /dev/random by default.

Check also:
https://elixir.bootlin.com/glibc/glibc-2.36/source/stdlib/arc4random.c

[shengwen-tw]

#70 resolves the issue here.