Le 29/12/2013 05:43, Emmanuel Dreyfus a écrit :
On Sun, Dec 29, 2013 at 03:05:12AM +0100, Jean-Yves Migeon wrote:It means that the RNG was seeded with a (supposedly) bad state, e.g. with not enough random bits to be deemed safe. It is generally not safe to keep long term keys generated during that state.IMO there is something to fix, as it is easy to miss the message during first boot.
The fix ain't that easy; how do you expect an environment to provide sufficient entropy when: - all devices and interrupts are virtualized therefore considerably reducing timestamp quality regarding entropy; - there is no trusted hardware entropy source queriable early during boot (rdrand OP is only found on recent Intel CPU, and some people do not consider it trustworthy).
For an interesting read, see http://mail-index.netbsd.org/port-xen/2012/02/24/msg007173.htmlI do not know whether sysinst could install a random_seed file right before restart; that would allow a first, fresh boot to begin with a (not so bad) entropy state.
domU situation adds another layer of limitation too: most of the time it does not start with /boot (except when using pygrub thingies), the kernel is directly loaded by dom0. So it cannot rely on rndseed from boot.cfg.
IMHO long term keys should not be created directly from a domU, let alone a VM; running a "dd if=/dev/random count=16 bs=1" can almost hang indefinetly in a domU, or (even worse) output not-so-random bits with other kind of VM subsystems (KVM without virtio-rng drivers). On a generic host it should return almost instantly.If I understand correctly, the only problem for keys generated in a NetBSD domU is performances?
No; entropy quality. Unless someone changed it recently, Manuel never considered frontend drivers as a good source of entropy. Other domUs can correlate their virtual interrupts and "guess" the timestamps for another VM. Side channels may also leak information on calculus, but that should not be your problem as you are not hosting hostile VMs, do you :) ?
If there is not enough randomness, it will just wait?
I would ask tls@ about current's cprng(9) behavior. IMHO that depends on the device you use to get entropy from: /dev/random may block for a very long time; while /dev/urandom will give you enough bytes back but with a weakly-seeded PRNG.
I never seen a standardized API for Xen domU to query randomness from dom0 (anyone is invited to prove me wrong). Perhaps virtio-rng from KVM is a possibility, but I do not know its architecture. It might not be suitable.
-- Jean-Yves Migeon