Interop.GetRandomBytes(): Use getrandom() if supported #1433
Conversation
|
(Figuring out now how to write benchmarks for this.) |
lpereira
force-pushed
the
use-getrandom-for-interop-getrandombytes
branch
from
869f99c to
578be74
Compare
Linux-specific getrandom(2) will generate random numbers drawing from the same pool as /dev/urandom when called with the GRND_NONBLOCK flag. This avoids having an open file descriptor at all times for random number generation. In order to introduce the possibility of using this system call, the code has been cleaned up as such: - Auxiliary functions have been introduced to fill a buffer with random numbers, for various different methods - Opening /dev/urandom will only happen if getrandom() or arc4random() aren't available; otherwise, no file descriptor will be used for that - XORing with results from lrand48() will only happen if we detect that the first few bytes are either 0- or 1-filled. There is a comment explaining the rationale. - Even if XORing is deemed necessary, the loop will now XOR 4 bytes at a time instead of just 1 at a time.
lpereira
force-pushed
the
use-getrandom-for-interop-getrandombytes
branch
from
578be74 to
dc381eb
Compare
|
|
||
| lastLrandRound = 0; | ||
| // Ensure dead store elimination does not yank the previous assignment | ||
| __asm__ __volatile__("" ::"g"(lastLrandRound) : "memory"); |
There was a problem hiding this comment.
I am not sure I understand why we assign to the variable right before it goes out of scope at all.
There was a problem hiding this comment.
It's a common defensive programming strategy to avoid having potentially sensitive data in some register. It doesn't guarantee much (e.g. vectorized memcpy() can keep stuff in SIMD registers), though.
There was a problem hiding this comment.
Why is it important to use this defensive strategy here?
|
@lpereira, what's the status of this? |
|
@lpereira informed me she won't be working on this any more, so I'm going to close it. If anyone's interested in completing it, please feel free to cherry-pick and open a new PR. Thanks. |
ghost
locked as resolved and limited conversation to collaborators
6 participants
Linux-specific getrandom(2) will generate random numbers drawing from the same pool as /dev/urandom when called with the GRND_NONBLOCK flag. This avoids having an open file descriptor at all times for random number generation.
In order to introduce the possibility of using this system call, the code has been cleaned up as such: