about summary refs log tree commit diff
path: root/compiler/rustc_passes/src/debugger_visualizer.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2022-05-20 23:11:12 +0000
committerbors <bors@rust-lang.org>2022-05-20 23:11:12 +0000
commite57884b6e96bede12447e21edcdc92fcac59ee46 (patch)
tree6a3124d7819e7ff58a024337a72d8246e078b6bd /compiler/rustc_passes/src/debugger_visualizer.rs
parente6a4afc3af2d2a53f91fc8a77bdfe94bea375b29 (diff)
parent18a9d58266dfb86a3e3e6b53a42798dd4348d93b (diff)
downloadrust-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