random: whitelist arc4random_buf if glibc #8984
Conversation
Glibc will soon implement the BSD arc4random API. whitelist its implementation as safe.
|
arc4random is a CSPRNG, but getrandom syacalll may give more favorable results. (I am not familiar with the arc4random implementation in glibc) Also, getrandom syscall seems to be much faster on latest Linux. |
|
Thanks for the pointers ! Let s leave it as is then. I myself mostly know BSD and macOs implementation (not 100% great thus this PR). Pretty interested by your RFC ;-) |
|
It all has to do with eliminating as much as possible the syscall overhead, which can be significant if called in a loop. the glibc implementation currently on last-steps review, uses the thread control block to store the state and a buffer of 256 bytes, it reseeds (so syscalls again only after) 16 MB of entropy is consumed. Other advantages are that it never blocks, it never fails, so all the error checking is avoided.. the failure path is again different from the BSD.. if for any reason it fails, the BSD versions abort..the glibc version fallbacks to raw getrandom and if that fails then terminates the program. |
|
What about this ... Let's revisit this a bit later, not a final no (from my part at least), but the RFC integration being the main point of focus (and trusting @zeriyoshi expertise on that matter) I do not feel the urgency at the moment, no complain about quality/perf so far. |
|
Oops, PR is closed... @crrodriguez I think this is a very good improvement if it doesn't affect the random number quality. |
Yes, latest version is here https://sourceware.org/pipermail/libc-alpha/2022-July/140627.html the later emails in the thread have arch-specific optimizations et.. |
|
@crrodriguez @devnexen |
|
@zeriyoshi Thanks for your input. |
|
@crrodriguez @devnexen This could improve performance on Linux distributions that do not have glibc, such as Alpine Linux. |
|
This is definitively a topic worth discussing IMHO. |
Yes, I refraining from suggesting this because it is for another topic.. as far as I am aware the currently most accepted construction is "A fast key erasure RNG" as suggested by D.J.Bernstein. https://blog.cr.yp.to/20170723-random.html |
Yes, I know. This is probably better discussed in the Internals ML. |
|
I have sent it. See you on the Internals ML. 😄 |
|
glibc now has arc4random but the above mentioned implementation was discarded due to security concerns, for now it calls getrandom with the appropiate error checking and has bsd compatible behaviour.. patch still stands. |
|
@crrodriguez Off topic: I was thinking it was not possible to vDSO getrandom for safety reasons, but I am curious what approach you would take. |
|
You do not need to revert it. it is safe.. and will later be improved as kernel/libc versions advance. |
This effectively reverts php#8984. As discussed in php#10327 which will enable the use of the getrandom(2) syscall on NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should prioritize security over speed [1] and history has shown that userland implementations unavoidably fall short on the security side. In fact the glibc implementation is a thin wrapper around the syscall due to security concerns and thus does not provide any benefit over just calling getrandom(2) ourselves. Even without any performance optimizations the CSPRNG should be plenty fast for the vast majority of applications, because they often only need a few bytes of randomness to generate a session ID. If speed is desired, the OO API offers faster, but non-cryptographically secure engines.
This effectively reverts #8984. As discussed in #10327 which will enable the use of the getrandom(2) syscall on NetBSD instead of relying on the userland arc4random_buf(), the CSPRNG should prioritize security over speed [1] and history has shown that userland implementations unavoidably fall short on the security side. In fact the glibc implementation is a thin wrapper around the syscall due to security concerns and thus does not provide any benefit over just calling getrandom(2) ourselves. Even without any performance optimizations the CSPRNG should be plenty fast for the vast majority of applications, because they often only need a few bytes of randomness to generate a session ID. If speed is desired, the OO API offers faster, but non-cryptographically secure engines.
Glibc will provide the BSD arc4random API, either on version 2.36 or slightly later.. whitelist its implementation as it uses the variant with modern crypto