Interface to the random number generator of the operating system.
|L4RE, SGX, UEFI||RDRAND|
|Hermit||RDRAND as |
Getrandom doesn't have a blanket implementation for all Unix-like operating
systems that reads from
/dev/urandom. This ensures all supported operating
systems are using the recommended interface and respect maximum buffer
By default, compiling
getrandom for an unsupported target will result in
a compilation error. If you want to build an application which uses
for such target, you can either:
[patch]section in your
Cargo.tomlto switch to a custom implementation with a support of your target.
- Enable the
dummyfeature to have getrandom use an implementation that always fails at run-time on unsupported targets.
Getrandom supports all of Rust's current
wasm32 targets, and it works with
both Node.js and web browsers. The three Emscripten targets
wasm32-experimental-emscripten use Emscripten's
The WASI target
wasm32-wasi uses the
defined by the WASI standard.
Getrandom also supports
wasm32-unknown-unknown by directly calling
stdweb. Getrandom supports using either one by enabling the
stdweb crate features. Note that if both features are
wasm-bindgen will be used. If neither feature is enabled, calls
getrandom will always fail at runtime.
It is possible that early in the boot process the OS hasn't had enough time yet to collect entropy to securely seed its RNG, especially on virtual machines.
Some operating systems always block the thread until the RNG is securely seeded. This can take anywhere from a few seconds to more than a minute. Others make a best effort to use a seed from before the shutdown and don't document much.
A few, Linux, NetBSD and Solaris, offer a choice between blocking and getting an error; in these cases we always choose to block.
On Linux (when the
getrandom system call is not available) and on NetBSD
/dev/urandom never blocks, even when the OS hasn't collected
enough entropy yet. To avoid returning low-entropy bytes, we first read from
/dev/random and only switch to
/dev/urandom once this has succeeded.
We always choose failure over returning insecure "random" bytes. In general,
on supported platforms, failure is highly unlikely, though not impossible.
If an error does occur, then it is likely that it will occur on every call to
getrandom, hence after the first successful call one can be reasonably
confident that no errors will occur.
On unsupported platforms,
getrandom always fails. See the
for more information on what data is returned on failure.
A small and