On Thu, May 21, 2026 at 4:28 PM <[email protected]> wrote:
>
> On Tue, May 19, 2026 at 03:16:00PM +0200, Hanno Böck wrote:
>
> > You can also fix this by uninstalling it.
>
> > There's no need to have an "entropy daemon"... It adds needless
> > complexity and, as this issue shows, attack surface. There have been
> > many improvements in the Linux kernel's RNG (Jason Donenfeld, also
> > known as the Wireguard developer, did a lot of work on that) and I
> > am quite confident that there are no problems with the RNG on any
> > reasonably recent Linux kernel that an "entropy daemon" would help
> > with.
>
> Wasn't most of the problem on VPSes, where hardware reads are
> simulated by the host and thus to some degree predictable? AFAIR that
> was the primary target of haveged. And that's why places like hetzner
> still include it in their default cloud-init setup, according to my
> experience :-(

Virtual Machines usually cause headaches for two reasons.  First is
playback attacks, where a vm is restarted from a past and known state.
The vm will produce the same bitstream for a while.  Second is the vm
fork.  Two vms will produce the same bitstreams for a while.  Also see
"Random numbers and virtual-machine forks",
<https://lwn.net/Articles/887207/>.

In both cases, I believe Hedging Deployed Cryptography could have
mitigated the problems, but it was never adopted by the kernel folks.
Also see "When Virtual is Harder than Real: Resource Allocation
Challenges in Virtual Machine Based IT Environments,"
<http://static.usenix.org/event/hotos05/final_papers/full_papers/garfinkel/garfinkel.pdf>;
and "When Good Randomness Goes Bad: Virtual Machine Reset
Vulnerabilities and Hedging Deployed Cryptography,"
<http://www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf>.

In the past (circa 2010 or so), I recall a couple other problems, but
I don't remember all the details.  One had to do with the way the host
vm or hypervisor fed random data to the guest vm using the VirtIO
driver.  The second had to do with the way hosting providers symlink'd
/dev/random to something [wrong] to avoid entropy deletion.

Jeff

Reply via email to