Use GRND_INSECURE instead of /dev/urandom when possible

[zx2c4]

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.

[rust-highfive]

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.

[zx2c4]

@faptc thanks for the review. Just committed your suggested changes.

[thomcc]

This looks fine to me, pending update of the constant.

[thomcc]

r? @thomcc

[thomcc]

A comment explaining (or linking to docs for) GRND_INSECURE wouldn't be out of place either, since it looks surprising.

[zx2c4]

Alright, constant updated, comment added. Should be good to go.

[thomcc]

@bors r+

[bors]

📌 Commit 309025c57e0c70a51cf98ad381c614dc5dc975cb has been approved by thomcc

[thomcc]

Ah, hm, is the constant not available yet?

[zx2c4]

What to make of the failure?

error[E0425]: cannot find value `GRND_INSECURE` in crate `libc`
  --> library/std/src/sys/unix/rand.rs:51:84
   |
51 |             let ret = unsafe { getrandom(buf.as_mut_ptr().cast(), buf.len(), libc::GRND_INSECURE) };
   |                                                                                    ^^^^^^^^^^^^^ not found in `libc`

Looks like it's actually not available?

[thomcc]

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.

[zx2c4]

Let's see if that does the trick.

[zx2c4]

Er, need to update the lock file. Futzing with it now...

[thomcc]

Running something like ./x.py check --stage 0 library/std locally should do the trick.

[zx2c4]

Thanks for the tip. All set now.

[thomcc]

@bors r+

[bors]

📌 Commit 18a9d58 has been approved by thomcc

[bors]

⌛ Testing commit 18a9d58 with merge e57884b...

[bors]

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing e57884b to master...

[rust-timer]

Finished benchmarking commit (e57884b): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	0	2	0	3	0
mean2	N/A	1.7%	N/A	-1.4%	N/A
max	N/A	2.2%	N/A	-1.6%	N/A

Cycles

Results

• Primary benchmarks: 😿 relevant regression found
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	1	2	0	1	1
mean2	3.2%	2.7%	N/A	-1.5%	3.2%
max	3.2%	3.2%	N/A	-1.5%	3.2%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. number of relevant changes ↩ ↩²

2. the arithmetic mean of the percent change ↩ ↩²