<= Archives =>
Failsafe API for entropy collection
2014/07/16 20:11:17 CEST

Stepping away from the noise of comments that this interesting article created all over the Internet, one can find a true gem in this file:

     * Try to use sysctl CTL_KERN, KERN_RANDOM, RANDOM_UUID.
     * sysctl is a failsafe API, so it guarantees a result. This
     * should work inside a chroot, or when file descriptors are
     * exhuasted.
     * However this can fail if the Linux kernel removes support
     * for sysctl. Starting in 2007, there have been efforts to
     * deprecate the sysctl API/ABI, and push callers towards use
     * of the chroot-unavailable fd-using /proc mechanism --
     * essentially the same problems as /dev/urandom.
     * Numerous setbacks have been encountered in their deprecation
     * schedule, so as of June 2014 the kernel ABI still exists on
     * most Linux architectures. The sysctl() stub in libc is missing
     * on some systems. There are also reports that some kernels
     * spew messages to the console.
    ret = getentropy_sysctl(buf, len);
    if (ret != -1)
        return (ret);
#endif /* CTL_MAXNAME */

    * Entropy collection via /dev/urandom and sysctl have failed.
    * No other API exists for collecting entropy. See the large
    * comment block above.
    * We have very few options:
    * - Even syslog_r is unsafe to call at this low level, so
    * there is no way to alert the user or program.
    * - Cannot call abort() because some systems have unsafe
    * corefiles.
    * - Could raise(SIGKILL) resulting in silent program termination.
    * - Return EIO, to hint that arc4random's stir function
    * should raise(SIGKILL)
    * - Do the best under the circumstances....
    * This code path exists to bring light to the issue that Linux
    * does not provide a failsafe API for entropy collection.
    * We hope this demonstrates that Linux should either retain their
    * sysctl ABI, or consider providing a new failsafe API which
    * works in a chroot or when file descriptors are exhausted.
    ret = getentropy_fallback(buf, len);

The scary function mentioned in the article is getentropy_fallback() (the link will show it). It has generated quite a wave of objections. Many people seem not to realize that, given the somewhat preview nature of LibreSSL portable, the code above should really be taken as a warning. And I find this is a wonderful way to give a warning!

There are also variants for OS X and Solaris. Can you guess which operating system has another sort of message? Check here.

Tags security libressl