Should the "rdrand" feature take precedence over the "target_os"?

[ghost]

Somewhat similarly to issue #346 (Should the "custom" feature take precedence ...) I think there should be a way to force use of RDRAND regardless of target_os or target_env.

Maybe something similar can be achieved by using #269 (Add support for forced custom ...), but it appears that just giving "rdrand" precedence (after "custom") would be a simpler solution.

Or, am I am missing something?

[josephlr]

I don't think this is something we would add to this crate. If an OS source of randomness is available, most security guidance recommends using that instead of RDRAND. On most common OSes, RDRAND is used as one of the entropy sources to the OS CSPRNG regardless. Also, at least on my x86 Linux machines, the performance is comparable.

Let me know I'm missing some reason we would want this.

[newpavlov]

I am too against introducing such feature. There are certain concerns about trusting RDRAND unconditionally (there is a fairly famous Linux discussion about it), since it's a black box which behavior can be modified by microcode updates.

Note that if you absolutely need it, you still can patch getrandom for your project and replace it with crate which uses RDRAND unconditionally. it would be slightly more involved than simply enabling a crate feature, but not terribly so.

[ghost]

Documentation says

//! ### RDRAND on x86
//!
//! If the rdrand Cargo feature is enabled, getrandom will fallback to using
//! the [RDRAND] instruction to get randomness on no_std x86/x86_64
//! targets. This feature has no effect on other CPU architectures.

---

There are projects which are both linux & no_std. Just one case

So
Either documentation should be corrected to get in-line with actual implementation or implementation should correspond to doc.

Otherwise current RDRAND feature only meaningful if OS is x86 but not Linux/Adroid not Win nor 64-bit Fuchisia.
Probably (technically) wrong in the above, but the question stands: "What does setting RDRAND feature of getrandom mean?"

---

Addressing potential weakness of older AMD implementations is much better address by explicit feature "care_about_old_buggy_amd_impl".

---

Unsafe (as not using safe RDRAND when available) should not be default.

Test question #1: "Where does it say that Linux distribution libc/kernel must use RDRAND when available?"
Test question #2: "How can we check answer to the question #1 in runtime?"

---

To reiterate: documentation is incorrect:
Today, if you compile to no_std Linux, <getrandom will fallback to using ! the [RDRAND] > is not happening.

[newpavlov]

By using "will fallback to" instead of "will use" documentation implies that RDRAND will be used only in cases when we do not have a "default" target-specific backend. But I can see how the current wording can cause incorrect understanding of the crate behavior. Feel free to submit a PR with doc clarifications.