Mark, I agree that the project area would be better for this discussion. For those not involved, this revolves around the vote to merge PR#9084 and possible alternate mitigations for the underlying problem.
Tim’s explanatory message is: > For the record, I think we need to do a better job of tackling the underlying > issue. > Dealing with systems on first boot with no entropy is an issue for a class of > systems. > However we should be distinguishing between contexts where we have decent > seeding material (from having had reasonable entropy) from those where we > haven't. > We also should be able to persist seeding across boots and have > recommendations for how vendors should do that. > We should be able to fall back to handling it at the user level (i.e. > non-root user, persisted in the file system). > We need knowledge of install state (for FIPS) and that can also act as a > first-boot state effectively. > > And this applies equally to getentropy usage - it is only a problem in very > limited contexts where blocking actually makes sense to perform. > That the kernel has no additional entropy available is not necessarily an > issue - except in a very limited context (first time boot with no other > entropy available from previous contexts). Viktor replied: > I just want to make sure we don't lock ourselves in to a single > potentially clumsy solution in the library. Various strategies > may be appropriate depending on the platform, and ultimately the > cooperation of the system administrator to enable the required > mechanisms. > > Potential additional sources for initial entropy on systems > without getrandom(2) might include: > > RDSEED/RDRAND > TPM (or Virtualized TPM which is sometimes better!) > RNG state saved across reboots. > ... > > This requires knowledge of various platforms, and potential > help from the platform vendors. It might, for example, make > sense to delegate initial seeding to systemd on platforms > that use systemd, and work with the systemd maintainers to > provide a set of sensible entropy sources for initial boot. > > Exposing a decent RNG to virtual guests and containers is > would be another area of focus. My suggestion as a fallback would be Stephan Müller’s CPU Jitter <http://chronox.de/jent/doc/CPU-Jitter-NPTRNG.html>. He’s collected a large corpus of data from many processors and the scheme works relatively quickly. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 7 Jun 2019, at 5:19 pm, Mark J Cox <m...@awe.com> wrote: > > Could we have this more detailed discussion on -project? > > Mark
