Use getentropy when possible on all Apple platforms #101011
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
T-libs
rust-highfive
added
the
S-waiting-on-review
BlackHoleFox
commented
Aug 25, 2022
| #[cfg(target_os = "watchos")] | ||
| #[cold] | ||
| fn fallback_fill_bytes(_: &mut [u8]) { | ||
| unreachable!() |
There was a problem hiding this comment.
This is a behavioral change, but not a breaking one afaict due to watchOS version support.
There was a problem hiding this comment.
I think it's not a behavioral change -- IIUC we don't support those versions of watchOS and tell the linker as much. Also, watchOS doesn't really work at the moment until rust-lang/libs-team#75 is resolved.
thomcc
approved these changes
Aug 25, 2022
| #[cfg(target_os = "watchos")] | ||
| #[cold] | ||
| fn fallback_fill_bytes(_: &mut [u8]) { | ||
| unreachable!() |
There was a problem hiding this comment.
I think it's not a behavioral change -- IIUC we don't support those versions of watchOS and tell the linker as much. Also, watchOS doesn't really work at the moment until rust-lang/libs-team#75 is resolved.
|
@bors r+ |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 31, 2022
…ents, r=thomcc Use getentropy when possible on all Apple platforms As the current code comments say, `SecRandomCopyBytes` is very heavyweight (regardless of purpose) compared to just asking the kernel directly for bytes from its own CSPRNG. We were not previously making an attempt to use the more efficient `getentropy` call on other Apple targets, instead solely using it on macOS. As the function is available on newer versions of Apple's different OSes, this changes the random filling to always attempt it first everywhere, only falling back to the less ideal alternatives after. This also cleans up the multiple Apple `imp` blocks into one. It also should give a perf improvement, even if its likely unnoticeably small. Refed XCode header for `getentropy` in the SDK: ```h int getentropy(void* buffer, size_t size) __OSX_AVAILABLE(10.12) __IOS_AVAILABLE(10.0) __TVOS_AVAILABLE(10.0) __WATCHOS_AVAILABLE(3.0); ``` r? `@thomcc`
This was referenced Aug 31, 2022
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 31, 2022
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#100970 (Allow deriving multipart suggestions) - rust-lang#100984 (Reinstate preloading of some dll imports) - rust-lang#101011 (Use getentropy when possible on all Apple platforms) - rust-lang#101025 (Add tier-3 support for powerpc64 and riscv64 openbsd) - rust-lang#101049 (Remove span fatal from ast lowering) - rust-lang#101100 (Make call suggestions more general and more accurate) - rust-lang#101171 (Fix UB from misalignment and provenance widening in `std::sys::windows`) - rust-lang#101185 (Tweak `WellFormedLoc`s a bit) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 24, 2023
…omcc Remove Apple RNG fallbacks and simplify implementation Now that we have [higher Apple platform requirements](rust-lang#104385), the RNG code can be simplified a lot. Since `getentropy` still doesn't look to be usable outside macOS this implementation: - Removes any macOS fallback paths and unconditionally links to `getentropy` - Minimizes the implementation for everything else (iOS, watchOS, etc). `CCRandomGenerateBytes` was added in iOS 8 which means that we can use it now. It and `SecRandomCopyBytes` have the exact same functionality, but the former has a simpler API and no longer requires libstd to link to `Security.framework` for one function. Its also available in all the other target's SDKs. Why care about `getentropy` then though on macOS? Well, its still much more performant. Benchmarking shows it runs at ~2x the speed of `CCRandomGenerateBytes`, which makes sense since it directly pulls from the kernel vs going through its own generator etc. Semi-related to a previous, but reverted, attempt at improving this logic in rust-lang#101011
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As the current code comments say,
SecRandomCopyBytesis very heavyweight (regardless of purpose) compared to just asking the kernel directly for bytes from its own CSPRNG. We were not previously making an attempt to use the more efficientgetentropycall on other Apple targets, instead solely using it on macOS. As the function is available on newer versions of Apple's different OSes, this changes the random filling to always attempt it first everywhere, only falling back to the less ideal alternatives after. This also cleans up the multiple Appleimpblocks into one.It also should give a perf improvement, even if its likely unnoticeably small.
Refed XCode header for
getentropyin the SDK:r? @thomcc