Let me see if I'm understanding this correctly. We don't want to use SecRandomCopyBytes because:

It makes linking more complex (Use getrandom crate rust-lang/rust#62082 (comment))
It incurs a notable startup cost (It makes startup time significantly longer on Mac rand#733)

First, iOS:

For iOS we would try getentropy first and fall back to SecRandomCopyBytes on ENOSYS as /dev/urandom is not directly accessible from the sandbox.

Both of the downsides to using SecRandomCopyBytes occur regardless of if we actually use it. So it would seem best to just only use SecRandomCopyBytes until the min Rust supported iOS version is iOS 10. When that happens, getentropy(2) should be added to the libc crate, and we should just call libc::getentropy. I've opened rust-lang/libc#1406 to figure out what the min iOS version should even be.

Now, macOS:

My suggestion would be to take the same approach on MacOS as Linux. Try the getentropy syscall first and fall back to reading /dev/(u)random on ENOSYS.

The main problem with this approach is that it's not supported on macOS. Unlike Linux, which has a stable syscall API, the stable API for macOS is the libc and other system libraries/frameworks. This means that there's not a way to "check" if getentropy is a supported syscall. It's either in the libc or it is not. For example, the libc crate has all the SYS_* numbers on Linux, but does not expose them on macOS, as they are unstable and an implementation detail.

Given this, it seems like the implementation options for macOS are:

Stick with using SecRandomCopyBytes
- Upsides: simple, same implementation as iOS
- Downsides: hard to link, and a (small) startup cost
Do what the solaris implementation does to dynamically see if getentropy is in the libc, and then fall back to /dev/random if it isn't there.
- Upsides: mitigates file descriptor depletion attack
- Downsides: very hacky, doesn't work well with miri (@RalfJung is this true?)
Just use /dev/random always:
- Upsides: very simple
- Downsides: file descriptor depletion attack
Just use libc::getentropy unconditionally
- Infeasible until min macOS version supported by Rust is 10.12

Despite it's weirdness, I think approch (2) is the best, as we already have similar implementations, and it seems to solve most of the problems raised in rust-lang/rust#62082

Use /dev/urandom on macOS #38

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions