Open newpavlov opened 1 year ago
getrandom
on Linux.getrandom
isn't available.getrandom
should not simulate a non-blocking syscall on systems that have no non-blocking API.#[cfg]
-based conditional code to access a non-blocking API. The API should be present everywhere, and in environments where it isn't available, it should return "no non-blocking API available."This suggests an API something like this:
#[must_use]
enum NonBlocking<'a> {
/// The system successfully filled the buffer with random data.
Filled(&'a [u8]),
/// The system is not ready to fulfill the request, but it might be ready later.
NotReady,
/// The system doesn't implement a non-blocking API.
NotImplemented
}
fn getrandom_nonblocking<'a>(dest: &'a mut [u8]) -> Result<NonBlocking<'a>> { ... }
fn getrandom_uninit_nonblocking<'a>(dest: &'a mut [MaybeUninit<u8>])) -> Result<NonBlocking<'a>> { ... }
I'm less eager to implement support for legacy non-blocking reading from "/dev/[u]random".
I agree. We could support sources which respect entropy estimates, but I don't think they are used much in practice nowadays.
The caller should implement their own fallback logic for when getrandom isn't available.
I think some platforms may provide randomness even if PRNG did not get enough initialization entropy (like /dev/urandom
on Linux and randABytes
on VxWorks). In such cases I think it would be better to return less secure randomness than ask users to implement their own fallback (which likely will be even less secure). In other words, we probably should add an option "give me random numbers even if they may be not secure enough".
Failing to get random bytes from a non-blocking call is not an error; it is an expected condition. It shouldn't be modeled as an error.
I think it's fine to return EAGAIN
-like errors when user has explicitly asked for a non-blocking source. Our API is relatively low level and "try again" error codes is a common approach with OS APIs.
To summarize, we probably need combination of the following options:
It may be represented as two separate options: quality of generated randomness and blocking behavior. The former also may include the "super secure" option to cover the GRND_RANDOM
flag.
Copying from #439
My proposed new API for this crate would be to introduce a getrandom::Opts
structure which would initially be empty, but could have fields added over time to support things like #365. This would allow us to introduce new functionality by just adding new fields to Opts
. Specifically, the API would be:
#[non_exhaustive] // Possible now that MSRV >= 1.40
#[derive(Clone, Copy, Debug, Default)]
pub struct Opts {}
impl Opts {
pub const fn new() -> Self;
}
pub fn fill(buf: &mut [u8], opts: Opts) -> Result<(), Error>;
/// Do we even want this? See discussion below
pub fn fill_uninit(buf: &mut [MaybeUninit<u8>], opts: Opts) -> Result<&mut [u8], Error>;
/// Convenience wrapper for `fill(buf, Opts::new())`
/// I don't think we would want to deprecate this.
pub fn getrandom(buf: &mut [u8]) -> Result<(), Error>;
register_custom_getrandom!()
I would propose having the register_custom_getrandom!
support both functions with the type of fill
and those with the type of fill_uninit
(if we keep the uninit
methods). We can use traits/generics to have the macro work with either function type. Similar to the current implementation, the macro would generate a #[no_mangle]
extern "Rust"
function, but it would have a different signature:
#[no_mangle]
unsafe fn __getrandom_fill(dest: *mut u8, len: usize, opts: *const Opts) -> u32;
I would also propose having the macro also create an unsafe fn __getrandom_custom(dest: *mut u8, len: usize)
function, allowing the custom implementation registered with the next version of getrandom
to still work with getrandom 0.2
without folks having to do tricks like those suggested in https://github.com/rust-random/getrandom/issues/433#issuecomment-2133355788
Which targets could even support non-blocking mode at all? For each one, how would it do so?
What would actually use this API? For which use case? At one point we thought maybe libstd would, but I don't think it will ever use getrandom, as it's already implemented what it needs itself.
The one option I know some people definitely need is "don't fall back to /dev/urandom, and don't link in the use_file
code at all unless something else in this process is using getrandom without this option." That would require a separate constructor for Opts
at least.
My initial ideas for flags in Opts
would be:
insecure
or best_effort
flag saying "try to get the best randomness the OS currently has, but try to avoid blocking on the OS to acquire more entropy"
GRND_INSECURE
HashMap
s or other non-cryptographic uses.
getrandom
.
In some scenarios (e.g. for seeding
HashMap
) it's desirable to get potentially less secure numbers than to block indefinitely. The motivation is largely equivalent to motivation behind theGRND_NONBLOCK
flag used in thegetrandom
syscall. We probably should add support for such scenarios, either by adding an additional argument or by introducing a separate set of non-blocking functions.Relevant PRs: #353 #352