On Mon, Jun 03, 2019 at 02:37:48PM +0200, Marco d'Itri wrote: > On Jun 03, Bastian Blank <wa...@debian.org> wrote: > > > Does anyone know what RHEL8 (which should have this problem as well) > > does to "fix" this problem? > RHEL8 enables by default rngd from rng-tools, which looks much better to > me than haveged.
rngd is indeed much better than haveged, which as the Arch Wiki has observed[1]: Warning: The quality of the generated entropy is not guaranteed and sometimes contested (see LCE: Do not play dice with random numbers[2] and Is it appropriate to use haveged as a source of entropy on virtual machines[3]?). Use it at your own risk or use it with a hardware based random number generator with the rng-tools (see #Alternative section) [1] https://wiki.archlinux.org/index.php/Haveged [2] https://lwn.net/Articles/525459/ [3] https://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines Unfortunately, rngd is better because it's not going to solve the problem which the OP articulated. Which is to say, it will use a hardware number generator if present, and it will use RDRAND if present --- both of which are good if you trust the hardware and --- but if the host is misconfigured, it's not going to help you. My opinion is we should darned will make sure the host is configured correctly, instead of playing dice with the guest VM's security. But there are people who are comforted by the "Yeah, I know the CPU is a deterministic system for the most part. But the CPU's cacheu architecture is ***sooooooo*** complicated that *I* can't figure it out, so it *MUST* be secure." - Ted
