Use getrandom on Linux for Guid generation for a 12% speed boost.#111287
Use getrandom on Linux for Guid generation for a 12% speed boost.#111287vcsjones wants to merge 6 commits intodotnet:mainfrom
Conversation
Since Linux 3.17, the syscall `getrandom` can be used to generate bytes from the same entropy source as `/dev/urandom`. This makes it suitable for cryptographic random number generation, something our Guid generator needs. If `getrandom` is not available because the LibC provided is too old - or if the syscall itself is not available, it will fall back to the previous method of reading from `/dev/urandom`. `EPERM` is treated like `ENOSYS` - some older Linux kernels returned this when the syscall is not available. The syscall can also be blocked by seccomp. That would be weird, and Docker permits it by default, but if anyone has explicitly gone out of their way to block it, it falls back to using the file descriptor mechanism. The use of the syscall implementation instead of the file device offers some performance improvements. Anywhere from 10% to 15% in benchmarks. This does require glibc 2.25. For non-portable builds, that's largely fine. For Microsoft builds, those are (currently) being done on Ubuntu Xenial, which has 2.23. However, it is expected that with .NET 10, the glibc floor is going to change to 2.27 with dotnet#109939. If that happens, then the Microsoft portable builds will pick this up as well. This PR does _not_ change the user-facing `RandomNumberGenerator` that will continue to use `RAND_bytes` from OpenSSL. | Method | Toolchain | Mean | Error | StdDev | Ratio | |--------------- |---------- |---------:|--------:|--------:|------:| | NewGuid | branch | 265.1 ns | 0.24 ns | 0.22 ns | 0.87 | | NewGuid | main | 304.6 ns | 0.16 ns | 0.15 ns | 1.00 | | | | | | | | | CreateVersion7 | branch | 293.2 ns | 0.20 ns | 0.18 ns | 0.88 | | CreateVersion7 | main | 335.0 ns | 0.27 ns | 0.23 ns | 1.00 |
ghost
added
the
jkoritzinsky
left a comment
jkoritzinsky
left a comment
There was a problem hiding this comment.
Can we extract the new code-path into a static function that returns true if getrandom was used and false if the device random should be used? I'd like to get rid of the goto if we can.
src/native/minipal/random.c
Outdated
| static bool sMissingGetRandomSysCall = false; | ||
|
|
||
| if (!sMissingGetRandomSysCall) |
There was a problem hiding this comment.
| static bool sMissingGetRandomSysCall = false; | |
| if (!sMissingGetRandomSysCall) | |
| static short sGetRandomSupport = -1; | |
| if (sGetRandomSupport == -1) | |
| { | |
| sGetRandomSupport = syscall(SYS_getrandom, nullptr, 0, GRND_NONBLOCK) == -1 && errno == ENOSYS ? 0 : 1; | |
| } | |
| if (sGetRandomSupport == 1) |
This run-time introspection will only run once; the first time.
There was a problem hiding this comment.
Why is this better than using the getrandom provided by the C runtime?
There was a problem hiding this comment.
The direct syscall has a small advantage in that it does not introduce hard dependency on the new glibc version, and so the binaries work in practice on older baselines too.
For example, even though our current baseline is Ubuntu 16, the binaries work in practice on older baselines too since we do not actually have a hard dependency on anything from Ubuntu 16 (it has been verified for native AOT compiled binaries, I am not sure about full coreclr).
|
This looks good. I missed that you already handled ENOSYS. :) It will also improve #31271 since it also ends up calling minipal implementation. @vcsjones, I posted a benchmark with managed impl. here, if case you want to try out #31271 (comment). |
This means that we have close to non-existing test coverage for this change. We do nearly all our testing in this repo on portable builds. We should either wait with merging this until we have updated the baseline, or define the syscall locally for portable builds like we have done in similar situations in the past see e.g. #111846 . |
|
I will take a look at doing a local definition. |
|
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
4 participants
Since Linux 3.17, the syscall
getrandomcan be used to generate bytes from the same entropy source as/dev/urandom. This makes it suitable for cryptographic random number generation, something our Guid generator needs.If
getrandomis not available because the LibC provided is too old - or if the syscall itself is not available, it will fall back to the previous method of reading from/dev/urandom.EPERMis treated likeENOSYS- some older Linux kernels returned this when the syscall is not available. The syscall can also be blocked by seccomp. That would be weird, and Docker permits it by default, but if anyone has explicitly gone out of their way to block it, it falls back to using the file descriptor mechanism.The use of the syscall implementation instead of the file device offers some performance improvements. Anywhere from 10% to 15% in benchmarks.
This does require glibc 2.25. For non-portable builds, that's largely fine. For Microsoft builds, those are (currently) being done on Ubuntu Xenial, which has 2.23. However, it is expected that with .NET 10, the glibc floor is going to change to 2.27 with #109939. When that happens, then the Microsoft portable builds will pick this up as well.
This PR does not change the user-facing
RandomNumberGeneratorthat will continue to useRAND_bytesfrom OpenSSL.