It should be possible to use a custom implementation when RDRAND is available

[briansmith]

See

getrandom/src/lib.rs

Lines 208 to 217 in 30308ae

	} else if #[cfg(all(target_arch = "x86_64", target_env = "sgx"))] {
	#[path = "rdrand.rs"] mod imp;
	} else if #[cfg(all(feature = "rdrand",
	any(target_arch = "x86_64", target_arch = "x86")))] {
	#[path = "rdrand.rs"] mod imp;
	} else if #[cfg(all(feature = "js",
	target_arch = "wasm32", target_os = "unknown"))] {
	#[path = "js.rs"] mod imp;
	} else if #[cfg(feature = "custom")] {
	use custom as imp;

:

Presently, the RDRAND implementation supersedes the custom implementation, and there's no way to prevent that for SGX or when the rdrand feature is explicitly set. Further, there's no way to use RDRAND through this crate from a custom implementation.

More generally, in any target we should be able to avoid using RDRAND output directly. For example, in an SGX and/or UEFI or operating system kernel, one may want to implement their own RNG, perhaps one that conforms to external security standards (FIPS, NIST, etc.), perhaps using RDRAND as one entropy source. Or, the implementation may want to mix the RDRAND output into a DRBG (using NIST terminology) to protect against unknown issues with RDRAND.

And, I think we getrandom even avoid defaulting to RDRAND on any target.

In UEFI and SGX, I would like to force the use of my custom implementation, and I'd like to implement mine partially in terms of RDRAND.

Concretely, I suggest:

1. Stop defaulting to the RDRAND implementation on SGX targets.
2. When the rdrand feature is requested, expose a new API to get the (raw, unbiased) results of RDRAND, independent of the current getrandom() API.
3. When the rdrand and custom features are requested, provide an API for registering the RDRAND implementation as the custom implementation, and document that environments such as UEFI and SGX must do this registration before using getrandom, just like any custom implementation.