According to the docs, getrandom will return -1 and errno will be EAGAIN when GRND_NONBLOCK is used and the entropy pool is not available. Should this include EAGAIN to try again?

I suspect that is probably not likely as I would think that would only happen only very early in the boot process, but, perhaps worth considering.

Yes, it's often the case during early boot scenarios, or on embedded systems. However, calling getrandom() in a tight loop if it keeps returning EAGAIN might turn into an infinite loop in such cases; I'm not sure it's advisable.

I have at least one VM that can take minutes to fully initialize.

Ubuntu 16.04.6

$ dmesg | grep random
[    1.844973] random: udevadm: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.846829] random: udevadm: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.849528] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.850996] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.852320] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.864731] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.866058] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.867459] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.870948] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[    1.872280] random: systemd-udevd: uninitialized urandom read (16 bytes read, 2 bits of entropy available)
[  180.310815] random: nonblocking pool is initialized

Newer kernels trust the CPU, so it's less likely:

Ubuntu 19.04:

$ dmesg | grep random
[    0.017218] random: get_random_bytes called from start_kernel+0x97/0x516 with crng_init=0
[    0.536646] random: crng done (trusting CPU's manufacturer)

Though not necessarily:

Ubuntu 18.04:

$ dmesg | grep random
[    0.000000] random: get_random_bytes called from start_kernel+0x99/0x4fd with crng_init=0
[    1.452697] random: fast init done
[    1.454713] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[    1.462508] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[    1.466497] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[   10.935718] random: crng init done
[   10.935721] random: 7 urandom warning(s) missed due to ratelimiting

So the EAGAIN either needs to fail over (e.g. to "dirty reads" from /dev/urandom), or the read should just be a blocking read. But it's definitely an important case to handle.

(Possibly it's already being handled OK, just that the assert needs to be removed)

The assert was just a copy from the read(/dev/urandom) codepath. Maybe a good idea to remove it from there.

BTW, not sure if you're able to set this up in your VM, but there is a virtio-rng device that some hypervisors implement (qemu-kvm being one of them) that provide entropy from the host to the guest; the Linux kernel is able to use it if detected.

@bartonjs Is the "no entropy available" message you're receiving on a fresh VM, or on a VM that has been rebooted? Per http://man7.org/linux/man-pages/man4/random.4.html:

If a seed file is saved across reboots as recommended below (all
major Linux distributions have done this since 2000 at least), the
output is cryptographically secure against attackers without local
root access as soon as it is reloaded in the boot sequence, and
perfectly adequate for network encryption session keys.

IMO blocking is the preferred behavior, especially if it happens only very rarely. If somebody's calling our APIs expecting high-entropy random values then we need to give them high-entropy random values. We can't pull a sleight of hand and give them low-entropy values.

IMO blocking is the preferred behavior

This caused significant problems when we were initially bringing up .NET on Linux. We initially had a blocking implementation, and start-up of the process could end up getting blocked for seconds, until the user wildly moved their mouse around to introduce entropy into the system.

Maybe what we're talking about here is a special case somehow, or maybe things have been improved on all distros/versions we now support, but I don't believe blocking waiting for sufficient entropy is viable.

FWIW, the Python crew considered this same problem a few years ago. They took a breaking change between Python 3.5.2 and Python 3.6 in order to make the os.urandom() function block on low-entropy scenarios because of the security risks inherent in the original behavior. See https://www.python.org/dev/peps/pep-0524/ for more information.

os.urandom returns bytes suitable for cryptographic use (https://docs.python.org/2/library/os.html#os.urandom).

SystemNative_GetNonCryptographicallySecureRandomBytes is not meant to be suitable for cryptographic use as the name suggests.

If this API isn't intended to produce strong randomness, we should reconsider having Guid.NewGuid depend on it. We know from experience that for better or worse, devs use Guid.NewGuid to produce random identifiers and expect those identifiers to have strong randomness.

Is it possible that a normal priority thread won the compare exchange, but a high priority thread gets stuck in here? Will that just deadlock, or will the high priority thread eventually yield anyways? (the description of sched_yield suggests that a single high priority thread just ignores the yield call).

There are no issues with the thread-safety around the reads of this field? e.g. is there any situation where the compiler/hardware might introduce a read such that it effectively became int a = fd; if (fd >= 0) return a;? (If that could happen we could end up returning -1.)