Re: deconflicting new syscall numbers for 6.11

[Russell Haley]

Since any PRNG will have the concept of re-seeding, I had to think
*really hard* to understand how a pseudo-generation number that really
means "reseed advised on change" could restrict future kernel
development, so for anyone else following along in the peanut gallery,
here's the scenario I came up with:

Suppose on some future CPU, RDRAND is improved to be essentially
perfect, with the same latency and throughput as a load from L1. So it
acts like a HWRNG, not a PRNG.  On such a CPU and with a command line
option that means "I 100% trust my CPU vendor," the kernel could
statically replace getrandom() with a function that just uses RDRAND,
and statically disable all the machinery for gathering entropy from
events and re-seeding the PRNG.

*Unless*, that is, userspace potentially needs to know when a
reseed-necessitating event has happened.

- Russell