[PATCH v2 0/5] random: fix initial seed entropy

[Stephen Hemminger <stephen@networkplumber.org>]

This series is about how the random number generator is seeded: where
the seed comes from, how it is expanded into the generator state, and
being able to pin it for repeatable test runs.

The build detection of getentropy() does not work, so DPDK has been
seeding its PRNG from RDSEED or the TSC on systems that do have
getentropy(). cc.has_function() probes with -std=c11, but glibc hides
getentropy() behind _DEFAULT_SOURCE, so the probe always fails.

A TSC derived seed only varies by process start time, which a local
attacker can determine.

  1/5 adds a Windows getentropy() shim over BCryptGenRandom(), so the
      EAL can call getentropy() unconditionally.
  2/5 drops the broken probe and always uses getentropy(). The TSC
      fallback remains but now logs at ERR with the errno, so a
      blocked syscall can be told apart from other failures.
  3/5 expands the seed with SplitMix64. The two halves of the seed
      were folded together and run through a 32 bit LCG, so only 32
      bits of the seed had any effect and the five state words had
      correlated low bits. Per-lcore seeds were the seed plus the
      lcore id, leaving neighbouring lcores with nearly identical
      state; that sum now goes through SplitMix64 as well. A given
      seed therefore produces a different sequence than in previous
      releases.
  4/5 removes the RDSEED fallback. It is unreachable once getentropy()
      is always used, and RDSEED has known reliability problems and
      errata. The kernel already mixes RDSEED into the pool that
      getentropy() draws from.
  5/5 adds a DPDK_TEST_SEED environment variable to the test
      application, so runs that build input data with rte_rand() can
      be made repeatable. Unset behaves as before.

Bugzilla ID: 2035

v2: - rebased
    - reduced patch series to only seedinr related changes

Two checks warn deliberately:

  1/5 carries Cc: stable@dpdk.org without a Fixes: tag. 2/5 is the
  stable candidate and does not build on Windows without the shim, so
  1/5 has to go back with it. The commit message says so.

  3/5 has a Fixes: tag and no Cc: stable. It changes the sequence a
  given seed produces, so a backport would change output for anyone
  relying on rte_srand() reproducibility on a stable branch.

Stephen Hemminger (5):
  eal/windows: add getentropy shim
  random: always use getentropy
  random: use all 64 bits of the seed
  random: remove RDSEED fallback for initial seed
  test: allow setting random seed for tests

 app/test/test.c                        | 48 +++++++++++++
 doc/guides/contributing/unit_test.rst  | 15 ++++
 doc/guides/rel_notes/release_26_11.rst | 10 +++
 lib/eal/common/rte_random.c            | 98 +++++++++++---------------
 lib/eal/include/rte_random.h           |  7 +-
 lib/eal/meson.build                    |  3 -
 lib/eal/windows/include/rte_os_shim.h  | 30 ++++++++
 lib/eal/windows/meson.build            |  6 +-
 8 files changed, 155 insertions(+), 62 deletions(-)

-- 
2.53.0