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.html
I 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
