Linux applications normally obtain cryptographic randomness from a kernel generator, rather than consuming one newly collected physical bit for every output bit. Initialization and state reuse still matter. A busy machine is not automatically safe, and a quiet machine is not automatically broken. Diagnose the interface, kernel version, and boot or cloning process before deciding that a counter proves a security failure.
Separate collection from output
The Linux 6.12 implementation mixes inputs into a BLAKE2s-based pool and uses ChaCha20 for output. These are implementation details of that version, not an eternal interface contract. Hardware sources, interrupt timing, and bootloader input contribute under platform-specific trust rules. Supplying bytes and crediting them toward initialization are separate operations; the kernel cannot assume arbitrary user-supplied bytes contain fresh unpredictability.
In that implementation, both poolsize and the initialized entropy counter reach 256 bits. Reads do not spend that counter like fuel. A historical manual’s 4096-bit description therefore should not become a universal alert threshold. Record the running kernel and inspect its behavior instead of claiming that every Linux version exposes identical counters or that a small number proves weak output.
Choose an initialization-aware interface
Default getrandom waits until initialization. GRND_NONBLOCK instead reports EAGAIN while initialization is incomplete, allowing an application to report the condition without hanging. Once initialized, a default-source request of at most 256 bytes has the documented full-read and signal guarantees; callers should still check errors and returned length. Larger requests need normal handling of partial results and interruptions.
The random device’s behavior changed in Linux 5.6: it no longer blocks for entropy depletion after initialization. In the inspected Linux 6.12 code, GRND_RANDOM does not select a separately depleting output pool. Some manual descriptions retain older behavior, so avoid combining their historical limits with current-kernel claims. Direct urandom reads can precede initialization; prefer the supported initialization-aware interface for early-boot key generation.
When it breaks
Early boot can still lack sufficient credited input. Missing device nodes in a container are a separate interface problem: getrandom does not require a device pathname, and ordinary containers share their host’s kernel. A blocked operation deserves an explicit startup failure or waiting policy, rather than replacing cryptographic randomness with timestamps, predictable seeds, or insecure fallback output.
A saved seed can improve the next boot, but writing a file back to urandom does not itself credit entropy. Neither a 32-byte file nor the mere presence of a hardware device proves immediate readiness. Use the distribution’s seed-management mechanism and its documented trust policy. Protect seed files, avoid shipping a common saved seed in cloned images, and keep any bootloader-specific seed handling aligned with the operating system.
Disk-image cloning and restoring a running virtual machine are different hazards. The first can copy seed files or already-generated host keys; the second can duplicate live generator state. Fresh inputs and VM-generation-ID handling can separate subsequent state. Identical future output is a risk to investigate, not an inevitable consequence of every clone. A seed shared by two machines alone does not establish that their entire generator states match.
Check it quickly
Run this Python 3 script on Linux. It reads counters and makes one nonblocking 32-byte request without printing random material, reading private keys, changing seed files, or requiring administrator access:
from pathlib import Path
import json
import os
import platform
def counters():
result = {}
for name in ("entropy_avail", "poolsize"):
try:
result[name] = int(Path("/proc/sys/kernel/random", name).read_text())
except OSError as error:
result[name] = type(error).__name__
return result
before = counters()
try:
sample = os.getrandom(32, os.GRND_NONBLOCK)
except BlockingIOError:
print(json.dumps({"kernel": platform.release(), "ready": False,
"counters": before}))
else:
assert len(sample) == 32
print(json.dumps({"kernel": platform.release(), "ready": True,
"bytes_returned": len(sample), "before": before,
"after": counters()}))
Retained audit output from Linux 6.18.44 with Python 3.12.14 reported ready=true, bytes_returned=32, and 256 for both counters before and after. These are observations from an already-initialized host, not a test of early boot, hardware quality, or restored virtual machines. For EAGAIN the program reports ready=false; that branch was not reproduced. This source-only review made no random request. Other syscall errors propagate rather than becoming an initialization verdict.
A successful call establishes that this interface supplied the requested bytes at this moment. It is not a statistical or cryptographic proof of unpredictability, and comparing two samples cannot provide that proof either. Restricted proc access may leave counter error names while the syscall still succeeds. Treat those outcomes separately instead of turning unavailable diagnostics into a claim of entropy failure.
Investigate identity reuse with direct evidence
A key’s modification time cannot prove which random source generated it. Files survive reboots, copying preserves timestamps, and clocks can move. Likewise, an inaccessible or missing initialization log is not proof of failed initialization. Inspect image preparation, key-generation code, boot policy, and duplicate public-key fingerprints. Rotate identities when actual duplication or exposure is established; do not infer compromised keys solely from a timestamp comparison.
Sources
- Linux 6.12 random implementation, initialization accounting, getrandom, sysctls, and VM-fork reseeding, checked 2026-10-15.
- Linux getrandom(2), initialization-aware calls, small reads, and errors; historical GRND_RANDOM details require version context, checked 2026-10-15.
- Linux random(4), uncredited writes and the Linux 5.6 blocking change; historical pool-size text is not current-kernel evidence, checked 2026-10-15.
- systemd 256 random-seed service, seed lifecycle, entropy-credit policy, and image preparation, checked 2026-10-15.
