Random.urandom converts its size with NUM2LEN instead of the unsigned macro, so a negative Integer raises ArgumentError without wrapping through the whole unsigned range first, and a size beyond the signed range raises RangeError the way Random#bytes already does. Neither error was covered before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Once rb_len_t widens this changes the `long *` output parameters of rb_range_beg_len(), rb_str_subpos(), rb_arithmetic_sequence_beg_len_step(), ruby_enc_find_basename() and ruby_enc_find_extname(), so extensions passing `long *` to them will need to be updated. The extension guides list these signatures verbatim and follow along.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`BCryptGenRandom` with `BCRYPT_USE_SYSTEM_PREFERRED_RNG` is available
on every supported Windows version and `bcrypt.lib` is linked
unconditionally on both mswin and mingw, so the deprecated CryptoAPI
fallback is unreachable in practice.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Set RUBY_TYPED_THREAD_SAFE_FREE on TypedData types whose dfree function
is trivially safe, and only frees its own memory
Types not yet marked as THREAD_SAFE_FREE:
- id2ref_tbl_type: sets the process-global id2ref_tbl to NULL.
- mutex_data_type: unlinks itself from another thread's keeping_mutexes list.
- autoload_data_type: deletes nodes from a shared intrusive list.
- autoload_const_type: deletes itself from a shared list.
- rb_cont_data_type: mutates the shared fiber pool and the global first_jit_cont list.
- rb_fiber_data_type: delegates to cont_free.
- FiberPoolDataType: mutates shared fiber pool free-lists.
- ractor_data_type: reconfigures global VM event-hook flags and call caches.
- exported_object_registry: frees a global table under the VM lock.
- rb_box_data_type (Box::Entry): unlinks classext from other live class and module objects.
- box_ext_cleanup_type: dereferences another String object and calls unlink.
- monitor_data_type: uses the default free, so the flag has no effect.
Co-authored-by: Luke Gruber <luke.gruber@shopify.com>
End procs are executed in reverse order of registration. Since the
crypt provider is initialized very early on via `Init_RandomSeedCore`,
no other end procs are executed after the crypt provider is released.
Finalizers are called after end procs, but their order is unspecified,
so there is still no guarantee that this crypt provider will be
available for use by other end procs.
As well as when `uint64_t` is not available. Although we now assume
that `uint64_t` is always available, even on 32-bit platforms, the
size of `st_index_t` is the same as a pointer and would be shorter
than 64-bit.
Fixes the following compiler warnings:
random.c: In function `random_init`:
random.c:416:38: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
416 | unsigned int major = rng->version.major;
| ~~~~~~~~~~~~^~~~~~
random.c: In function `random_bytes`:
random.c:1284:8: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
1284 | rng->get_bytes(rnd, ptr, n);
| ~~~^~~~~~~~~~~
random.c:1299:34: note: `rng` was declared here
1299 | const rb_random_interface_t *rng;
| ^~~
random.c: In function `rand_random_number`:
random.c:1606:12: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
1606 | return rand_range(obj, rng, rnd, vmax);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
random.c:1624:34: note: `rng` was declared here
1624 | const rb_random_interface_t *rng;
| ^~~
random.c: In function `random_rand`:
random.c:1120:15: warning: `rng` may be used uninitialized in this function [-Wmaybe-uninitialized]
1120 | return rng->get_int32(rnd);
| ~~~^~~~~~~~~~~
random.c:1573:34: note: `rng` was declared here
1573 | const rb_random_interface_t *rng;
| ^~~
* [DOC] Clarify differences between Kernel.rand and Random.rand
* `Kernel.rand` converts the `max` Float argument to Integer and returns Integer values
* `Random.rand` preserves the `max` Float argument and returns Float values
* Added examples demonstrating the behavioral differences
We recently converted this to be WB_PROTECTED, but missed some locations
the seed was set.
This is a little bit confusing because as far as I can tell some of the
seeds are set in Ractor local storage, and others on actual objects.
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.
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.
When loading a crafted marshal data of Random, a pointer to an illegal
address was created. I don't think there is any harm since the data is
normalized before access, but just to be safe, I add a check to make it
an error.
Do not retry `fill_random_bytes` in `Init_RandomSeedCore`, just after
it failed first.
In other places, `rand_init_default` and `random_seed`, no more tweeks
needed once it succeeded
This `st_table` is used to both mark and pin classes
defined from the C API. But `vm->mark_object_ary` already
does both much more efficiently.
Currently a Ruby process starts with 252 rooted classes,
which uses `7224B` in an `st_table` or `2016B` in an `RArray`.
So a baseline of 5kB saved, but since `mark_object_ary` is
preallocated with `1024` slots but only use `405` of them,
it's a net `7kB` save.
`vm->mark_object_ary` is also being refactored.
Prior to this changes, `mark_object_ary` was a regular `RArray`, but
since this allows for references to be moved, it was marked a second
time from `rb_vm_mark()` to pin these objects.
This has the detrimental effect of marking these references on every
minors even though it's a mostly append only list.
But using a custom TypedData we can save from having to mark
all the references on minor GC runs.
Addtionally, immediate values are now ignored and not appended
to `vm->mark_object_ary` as it's just wasted space.
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.
