gcry_create_nonce after a snapshot or checkpoint restore

[Yuxiang Ji]

We measure how userspace random generators behave when a process or a 
machine is duplicated, and would like to know where libgcrypt places one 
case before we write it up. libgcrypt 1.12.2 as shipped by Fedora 44, 
source read at 1ff517245292; Linux 7.2.11, glibc 2.43; the harness and 
every log are available.

What the source and manual say. random/random.c 521 to 548: the nonce 
buffer is reseeded when the pid changed ("We forked. Need to reseed the 
buffer"). doc/gcrypt.texi 6657 to 6658: "Process fork detection and 
protection is implemented." 4780 to 4787: gcry_create_nonce fills a 
buffer "with length unpredictable bytes", kept "nearly independent of 
the other random function" to protect the regular generator's state and 
the entropy pool. gcry_randomize at GCRY_STRONG_RANDOM draws from the 
kernel on every call in this build (random/rndgetentropy.c 74 to 105).

What we measured (two children of one parent, 32 blocks each, compared 
at equal sequence numbers): the nonce generator is 0 of 32 identical 
after fork(), glibc's _Fork() and raw clone(), and 32 of 32 identical 
when a pid-1 parent clones into a new pid namespace, where the child is 
pid 1 too. The strong level is 0 of 32 everywhere, being the kernel's 
output.

Restores (one guest or process saved and restored twice, the 
continuations compared): the nonce generator is 32 of 32 identical under 
QEMU with and without a vmgenid device and with a VMClock device, under 
Firecracker with VMGenID and VMClock attached, and 14 of 14 under CRIU; 
the strong level and the kernel's getrandom beside it are distinct from 
the first block wherever the vmgenid driver is present.

Questions.

1. Is a nonce buffer that continues from the saved state after a 
snapshot or checkpoint restore inside what gcry_create_nonce promises? 
The manual's "unpredictable bytes" and the separation from the strong 
generator read as a deliberate weaker contract; we would like to report 
it as the project sees it.
2. If it is in scope: Linux 7.0 exposes a VMClock page with a 
vm_generation_counter that a process can map and compare before each 
output; a compare beside the pid check in random/random.c is one load 
under a sequence count. We have measured a check of that shape in three 
other libraries and can offer one.
3. If it is out of scope, would a sentence in the manual beside the fork 
sentence say so?

The repeated blocks are the generator's own output; we have not looked 
at anything downstream.

Regards,
Yuxiang Ji