diff options
| author | bors <bors@rust-lang.org> | 2022-05-20 23:11:12 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2022-05-20 23:11:12 +0000 |
| commit | e57884b6e96bede12447e21edcdc92fcac59ee46 (patch) | |
| tree | 6a3124d7819e7ff58a024337a72d8246e078b6bd /compiler/rustc_passes/src/debugger_visualizer.rs | |
| parent | e6a4afc3af2d2a53f91fc8a77bdfe94bea375b29 (diff) | |
| parent | 18a9d58266dfb86a3e3e6b53a42798dd4348d93b (diff) | |
| download | rust-e57884b6e96bede12447e21edcdc92fcac59ee46.tar.gz rust-e57884b6e96bede12447e21edcdc92fcac59ee46.zip | |
Auto merge of #95824 - zx2c4-forks:grnd_insecure, r=thomcc
Use GRND_INSECURE instead of /dev/urandom when possible From reading the source code, it appears like the desired semantic of std::unix::rand is to always provide some bytes and never block. For that reason GRND_NONBLOCK is checked before calling getrandom(0), so that getrandom(0) won't block. If it would block, then the function falls back to using /dev/urandom, which for the time being doesn't block. There are some drawbacks to using /dev/urandom, however, and so getrandom(GRND_INSECURE) was created as a replacement for this exact circumstance. getrandom(GRND_INSECURE) is the same as /dev/urandom, except: - It won't leave a warning in dmesg if used at early boot time, which is a common occurance (and the reason why I found this issue); - It won't introduce a tiny delay at early boot on newer kernels when /dev/urandom tries to opportunistically create jitter entropy; - It only requires 1 syscall, rather than 3. Other than that, it returns the same "quality" of randomness as /dev/urandom, and never blocks. It's only available on kernels ≥5.6, so we try to use it, cache the result of that attempt, and fall back to to the previous code if it didn't work.
Diffstat (limited to 'compiler/rustc_passes/src/debugger_visualizer.rs')
0 files changed, 0 insertions, 0 deletions
