[Bug #21448] Use `getentropy(2)` only on macOS
If this is not a system call, then it is using getrandom (which would
have been tried already), and cannot be used as a replacement for the
random devices.
Restore getrandom(2) path for Linux with glibc 2.36 or later
This is a follow-up to commit b120f5e38d (avoid fork-unsafe arc4random
implementations, 2018-09-04).
Avoid defining a no-op fill_random_bytes_syscall() if arc4random_buf(3)
exists, but we are unsure if it is fork-safe. Check for other options
instead. IOW, see if getrandom(2) is available.
glibc 2.36, released in 2022, started to provide arc4random_buf(3) on
Linux. This causes fill_random_bytes_syscall() to use neither of them
and makes Random.urandom solely rely on getentropy(3) via
fill_random_bytes_urandom().
While the glibc implementation is safe, I did not add it to the list
because using getrandom(2) directly is preferable on Linux.
[Bug #21448] Reorder trials in `fill_random_bytes`
First try dedicated system calls, such as `getrandom` or `getentropy`,
next possible libraries, then fallback to `/dev/urandom`.
when the RUBY_FREE_ON_SHUTDOWN environment variable is set, manually free memory at shutdown.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Peter Zhu <peter@peterzhu.ca>
This is a follow-up for commit 265c002239 ("Do not allocate
ractor-local storage in dfree function during GC", 2021-02-09).
The comparison with the default rb_random_mt_t is useless in the first
place, since it is never equal: no actual Random object is associated
with it.
[Bug #17653] https://bugs.ruby-lang.org/issues/17653
Security/Authorization.h defines AuthorizationExternalForm by
using clang extension which allows variably modified types in a
file scope. As we just need high-level accessors only, include
Security/SecRandom.h instead.
To manage ractor-local data for C extension, the following APIs
are defined.
* rb_ractor_local_storage_value_newkey
* rb_ractor_local_storage_value
* rb_ractor_local_storage_value_set
* rb_ractor_local_storage_ptr_newkey
* rb_ractor_local_storage_ptr
* rb_ractor_local_storage_ptr_set
At first, you need to create a key of storage by
rb_ractor_local_(value|ptr)_newkey().
For ptr storage, it accepts the type of storage,
how to mark and how to free with ractor's lifetime.
rb_ractor_local_storage_value/set are used to access a VALUE
and rb_ractor_local_storage_ptr/set are used to access a pointer.
random.c uses this API.
Random generators are not Ractor-safe, so we need to prepare
per-ractor default random genearators. This patch set
`Random::DEFAULT = Randm` (not a Random instance, but the Random
class) and singleton methods like `Random.rand()` use a per-ractor
random generator.
[Feature #17322]
Added `WITH_REAL` versions to `RB_RANDOM_INTERFACE` macros. Also
these macros including "without real" versions no longer contain
the terminator (semicolon and comma).
* random.c: separate abstract rb_random_t and rb_random_mt_t for
Mersenne Twister implementation.
* include/ruby/random.h: the interface for extensions of Random
class.
* DLL imported symbol reference is not constant on Windows.
* check if properly initialized.
RARRAY_AREF has been a macro for reasons. We might not be able to
change that for public APIs, but why not relax the situation internally
to make it an inline function.
