| apple_other.rs |
Implementation for iOS, tvOS, and watchOS where `getentropy` is unavailable. |
626 |
| custom.rs |
An implementation which calls out to an externally defined function. |
424 |
| esp_idf.rs |
Implementation for ESP-IDF |
819 |
| fuchsia.rs |
Implementation for Fuchsia Zircon |
383 |
| getentropy.rs |
Implementation using getentropy(2)
Available since:
- macOS 10.12
- OpenBSD 5.6
- Emscripten 2.0.5
- vita newlib since Dec 2021
For these targets, we use getentropy(2) because getrandom(2) doesn't exist. |
711 |
| getrandom.rs |
Implementation using getrandom(2).
Available since:
- Linux Kernel 3.17, Glibc 2.25, Musl 1.1.20
- Android API level 23 (Marshmallow)
- NetBSD 10.0
- FreeBSD 12.0
- illumos since Dec 2018
- DragonFly 5.7
- Hurd Glibc 2.31
- shim-3ds since Feb 2022
For these platforms, we always use the default pool and never set the
GRND_RANDOM flag to use the /dev/random pool. On Linux/Android/Hurd, using
GRND_RANDOM is not recommended. On NetBSD/FreeBSD/Dragonfly/3ds, it does
nothing. On illumos, the default pool is used to implement getentropy(2),
so we assume it is acceptable here. |
1016 |
| hermit.rs |
Implementation for Hermit |
1825 |
| linux_android.rs |
Implementation for Linux / Android without `/dev/urandom` fallback |
556 |
| linux_android_with_fallback.rs |
Implementation for Linux / Android with `/dev/urandom` fallback |
3419 |
| netbsd.rs |
Implementation for NetBSD
`getrandom(2)` was introduced in NetBSD 10. To support older versions we
implement our own weak linkage to it, and provide a fallback based on the
KERN_ARND sysctl. |
2714 |
| rdrand.rs |
RDRAND backend for x86(-64) targets |
5731 |
| rndr.rs |
RNDR register backend for aarch64 targets
Arm Architecture Reference Manual for A-profile architecture:
ARM DDI 0487K.a, ID032224, D23.2.147 RNDR, Random Number |
4715 |
| solaris.rs |
Solaris implementation using getrandom(2).
While getrandom(2) has been available since Solaris 11.3, it has a few
quirks not present on other OSes. First, on Solaris 11.3, calls will always
fail if bufsz > 1024. Second, it will always either fail or completely fill
the buffer (returning bufsz). Third, error is indicated by returning 0,
rather than by returning -1. Finally, "if GRND_RANDOM is not specified
then getrandom(2) is always a non blocking call". This _might_ imply that
in early-boot scenarios with low entropy, getrandom(2) will not properly
block. To be safe, we set GRND_RANDOM, mirroring the man page examples.
For more information, see the man page linked in lib.rs and this blog post:
https://blogs.oracle.com/solaris/post/solaris-new-system-calls-getentropy2-and-getrandom2
which also explains why this crate should not use getentropy(2). |
1851 |
| solid.rs |
Implementation for SOLID |
643 |
| use_file.rs |
Implementations that just need to read from a file |
8653 |
| vxworks.rs |
Implementation for VxWorks |
1513 |
| wasi_p1.rs |
Implementation for WASI Preview 1 |
1143 |
| wasi_p2.rs |
Implementation for WASI Preview 2. |
1380 |
| wasm_js.rs |
Implementation for WASM based on Web and Node.js |
2581 |
| windows.rs |
Implementation for Windows 10 and later
On Windows 10 and later, ProcessPrng "is the primary interface to the
user-mode per-processor PRNGs" and only requires bcryptprimitives.dll,
making it a better option than the other Windows RNG APIs:
- BCryptGenRandom: https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom
- Requires bcrypt.dll (which loads bcryptprimitives.dll anyway)
- Can cause crashes/hangs as BCrypt accesses the Windows Registry:
https://github.com/rust-lang/rust/issues/99341
- Causes issues inside sandboxed code:
https://issues.chromium.org/issues/40277768
- CryptGenRandom: https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
- Deprecated and not available on UWP targets
- Requires advapi32.lib/advapi32.dll (in addition to bcryptprimitives.dll)
- Thin wrapper around ProcessPrng
- RtlGenRandom: https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlgenrandom
- Deprecated and not available on UWP targets
- Requires advapi32.dll (in addition to bcryptprimitives.dll)
- Requires using name "SystemFunction036"
- Thin wrapper around ProcessPrng
For more information see the Windows RNG Whitepaper: https://aka.ms/win10rng |
2540 |
| windows7.rs |
Legacy implementation for Windows XP and later
For targets where we cannot use ProcessPrng (added in Windows 10), we use
RtlGenRandom. See windows.rs for a more detailed discussion of the Windows
RNG APIs (and why we don't use BCryptGenRandom). On versions prior to
Windows 10, this implementation is secure. On Windows 10 and later, this
implementation behaves identically to the windows.rs implementation, except
that it forces the loading of an additonal DLL (advapi32.dll).
This implementation will not work on UWP targets (which lack advapi32.dll),
but such targets require Windows 10, so can use the standard implementation. |
1962 |