I searched for users of RNDADDTOENTCNT using
(?s:ioctl.{1,500}RNDADDTOENTCNT) on Debian Code Search and
"/(?s)ioctl.{1,40},\s*RNDADDTOENTCNT/ -path:incfs_test.c" on GitHub Code
Search (beta).
Several programs use it for testing purposes, without writing any
entropy to /dev/random or /dev/urandom, including rauc, wireguard, and
openSUSE kdump. Several programs use it as intended, after writing
entropy to /dev/random or /dev/urandom. Of the latter group,
- kata-containers is a lightweight VM implementation. Its guest-side
agent offers a gRPC endpoint which will write the provided data to
/dev/random, then call RNDADDTOENTCNT with the length of the data,
then call RNDRESEEDRNG. As far as I can tell, this endpoint is
made available to users on the host, but is not used by
kata-containers itself.
- aws-nitro-enclaves-sdk-c is an SDK for building lightweight VMs to be
used with AWS Nitro Enclaves. kmstool-enclave is a sample application
provided, which writes "up to 256 bytes" (from where?) to /dev/random,
then calls RNDADDTOENTCNT, then repeats the process until it reaches
1024 bytes.
- sandy-harris/maxwell is a "jitter entropy" daemon, similar to haveged.
It writes 4 bytes of "generated entropy" to /dev/random, then calls
RNDADDTOENTCNT, then repeats.
- guix is, among other things, a "GNU/"Linux distribution. The provided
base services write the seed file to /dev/urandom, then call
RNDADDTOENTCNT, then write 512 bytes from /dev/hwrng to /dev/urandom,
then call RNDADDTOENTCNT, then "immediately" read 512 bytes from
/dev/urandom and write it to the seed file. On shutdown, 512 bytes are
read from /dev/urandom and written to the seed file.
I was unable to locate any other public non-archived usages of
RNDADDTOENTCNT on Debian or GitHub Code Search.
I don't have any particular expertise with the random subsystem or
conclusions to make from this data, but I hope this helps inform the
discussion.
Cheers,
Alex.
