[not-matthias]

TLDR: Hash-seed randomness (Rust RandomState, CPython hash seed, glibc canary) changes bucket collisions and probe lengths between runs, which shows up as instruction-count noise. --deterministic-rng=yes serves every randomness source a client can observe from a fixed-seed PRNG (Linux only; time, pid and tid are deliberately untouched).

Core

• AT_RANDOM auxv bytes come from a dedicated PRNG stream.
• Each client thread gets its own splitmix64 stream, keyed by a monotonic creation counter (not the ThreadState slot), so the N-th created thread draws the same bytes whichever slot it reuses.

Syswrap

• getrandom(2) completes in the PRE wrapper and never enters the kernel.
• fds on /dev/random and /dev/urandom (resolved through /proc/self/fd) are tracked across open*, dup*, fcntl F_DUPFD*, close and close_range; read, pread64, readv, preadv, preadv2 on them are served from the PRNG.
• Served paths keep kernel errors: a non-writable client buffer fails with EFAULT, and a device fd is only tracked if a zero-length read succeeds, so O_WRONLY and O_PATH fds keep the kernel's EBADF.
• Served paths clear SfMayBlock; a PRE that completes a syscall must not keep it (syswrap-main.c:2440).

VEX (amd64)

• When the host supports RDRAND/RDSEED, they draw from the calling thread's stream through a new LibVEX_SetRandom32 callback and always report success.
• CPUID and decoding still follow the host: on hosts without them, they are neither advertised nor decoded, exactly as without the option. With the option off, the helpers run the host instructions as before.

Review notes

• Option is parsed in the early pass because VG_(ii_create_image) writes AT_RANDOM before the main pass.
• A forked child continues its parent's streams; under --trace-children=yes each exec'd program restarts from the seed.
• Bytes depend on which thread makes the call, so runtimes that move work between threads based on timing (thread pools, work stealing, Go goroutines) can still vary.
• PRNG output uses host byte order; only little-endian targets are supported for now.
• Regtests: callgrind/tests/deterministic_rng pins the bytes per source, each draw on a fresh thread so libc's startup getrandom calls cannot shift the expectation, and checks the EFAULT/EBADF cases. none/tests/amd64/deterministic_rng covers RDRAND/RDSEED for every operand width, flags, stream advance and fresh threads; it only runs on hosts with both instructions.

[codspeed]

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 60 skipped benchmarks¹

---

_{Comparing cod-3957-determinstic-rng (7a783cb) with master (908f432)}

Footnotes

1. 60 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[greptile-apps]

Confidence Score: 5/5

[High impact] The PR appears safe to merge with the stated platform limits.

Summary

Adds opt-in reproducible randomness through --deterministic-rng=yes.

• Linux clients can draw covered random values from fixed-seed streams.
• On amd64, RDRAND and RDSEED use the caller's deterministic stream.

Previously accepted limits remain unchanged: not-matthias deferred portability guards because their execution targets have the required APIs, excluded big-endian and non-Linux targets, accepted private descriptor-table limits because Valgrind already shares them, and set Ubuntu 24.04+ as the toolchain baseline.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A["--deterministic-rng=yes"] --> B["Dedicated startup stream"]
  A --> C["Per-thread stream"]
  A --> D["Fixed boot UUID stream"]
  B --> E["AT_RANDOM"]
  C --> F["getrandom and random-device reads"]
  C --> G["RDRAND and RDSEED"]
  C --> H["Proc UUID text"]
  D --> I["Proc boot_id text"]
  J["Kernel preserves proc read results"] --> H
  J --> I

Loading

_{Reviews (5) · Last reviewed commit: "feat(callgrind): make proc UUID reads de..." · Reviewed by Greptile}

[GuillaumeLagrange]

LGTM, although thorough testing will be required

[art049]

Looks good to me on the approach although as mentionned in the changelog, we still miss some non deterministic randomness.

Would it be hard to cover /proc/sys/kernel/random/* devices?
For example /proc/sys/kernel/random/uuid might be widely used, pretty sure there are others

For clock_gettime definitely this will be a mess with certificates and a lot of other things so let's not deal with it now.

I think we need to cover arm64 for cpu level randomness.

[not-matthias]

Looks good to me on the approach although as mentionned in the changelog, we still miss some non deterministic randomness.

Would it be hard to cover /proc/sys/kernel/random/* devices? For example /proc/sys/kernel/random/uuid might be widely used, pretty sure there are others

For clock_gettime definitely this will be a mess with certificates and a lot of other things so let's not deal with it now.

I think we need to cover arm64 for cpu level randomness.

Implemented support for some /proc/sys/kernel/random/* variables that can be spoofed. See:
7a783cb (this PR)