New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use GRND_INSECURE instead of /dev/urandom when possible #95824
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon. Please see the contribution instructions for more information. |
This comment has been minimized.
This comment has been minimized.
f38e3e9
to
2495bb7
Compare
@faptc thanks for the review. Just committed your suggested changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me, pending update of the constant.
r? @thomcc |
A comment explaining (or linking to docs for) GRND_INSECURE wouldn't be out of place either, since it looks surprising. |
Alright, constant updated, comment added. Should be good to go. |
@bors r+ |
📌 Commit 309025c57e0c70a51cf98ad381c614dc5dc975cb has been approved by |
Ah, hm, is the constant not available yet? |
What to make of the failure?
Looks like it's actually not available? |
https://github.com/rust-lang/rust/blob/master/library/std/Cargo.toml#L18 If you bump this to 0.2.126, it should be fine. Please do it in a separate commit. |
Let's see if that does the trick. |
Er, need to update the lock file. Futzing with it now... |
Running something like |
This is required for the next commit, which uses libc::GRND_INSECURE.
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.
Thanks for the tip. All set now. |
@bors r+ |
📌 Commit 18a9d58 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e57884b): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
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.