Ian Lepore <i...@freebsd.org> writes:
> Dag-Erling Smørgrav <d...@des.no> writes:
> > That means we're not getting enough entropy during early boot, or
> > we're underestimating the amount of entropy we're getting. We added
> > entropy harvesting to device_attach() about a year ago, which in
> > most cases provides enough entropy to unblock /dev/random before we
> > even run init(8).
> And I vaguely remember being promised that things like that would
> NEVER happen, even on systems with little or no entropy available
> during early startup (which describes quite nicely the embedded
> systems we build at work).
I think you misremember. It is impossible to guarantee that the system
will always have enough entropy right from the start. Servers, desktops
and laptops will be fine, but embedded systems and VMs might not be able
to unblock until they've seen some network traffic or loaded a chunk of
pre-generated entropy (which is what /etc/rc.d/random does). This is
especially true for embedded systems that don't have enumerable buses
and rely on fdt(4) to create the device tree at boot time.
VMs have the additional problem of divergence between clones: if you
clone a VM, all clones will start out with the exact same state and
won't diverge until they've all reseeded after gathering entropy
independently of eachother. I don't really know how to solve this. One
possibility, assuming you have guest additions installed and that they
can tell you that you've been suspended, is to block on resume. It
won't help VMs that were cloned while shut down, but they should diverge
to some extent during boot.
Dag-Erling Smørgrav - d...@des.no
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"