[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Stalls due to insufficient randomness in cloud images



On Mon, Jun 03, 2019 at 02:37:48PM +0200, Marco d'Itri wrote:
> On Jun 03, Bastian Blank <waldi@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


Reply to: