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]

It will be great if someone is interested in investigating the problem of arc4random_buf(), as I will probably keep working on the virtio-gpu implementation.