On 05/05/2014 04:35 PM, Lennart Poettering wrote:
On Wed, 30.04.14 17:06, Florian Weimer (fwei...@redhat.com) wrote:
On 04/30/2014 02:28 PM, Daniel P. Berrange wrote:
Interesting suggestion. I just used virt-manager to create the VM.
I don't see any trace for "rng" or "random" in the domain XML file.
If it is supported, I think it should be enabled by default.
I'm told that it isn't turned on by default, but you can add it to
a VM post-install. Since it feeds VMs from the host's /dev/random
or /dev/hwrng, there was a question mark as to whether it was right
to enable it by default or not, and if so what kind of rate limiting
might be wanted by default.
Ah, so it builds down to our distrust of hardware RNGs? How
annoying. We should be able to trust Fedora-on-Fedora (or
Debian-on-Debian or whatever) scenarios. But I get that in the
general case, it's impossible to know what's on the other side of
the virtio_rng side, so reservations remain.
Hmm? Well, a virtualized OS has to trust the hypervisor, there's no way
around that.
I'm referring to this:
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
* is impossible to verify that it is implemented securely (as
* opposed, to, say, the AES encryption of a sequence number using a
* key known by the NSA). So it's useful if we need the speed, but
* only if we're willing to trust the hardware manufacturer not to
* have put in a back door.
I think this is the reason why the pool isn't considered initialized
even if its contents has been randomized with RDRAND or similar
instructions.
I wouldn't be surprised if these minds have a similar concern about
randomness coming from a hypervisor.
--
Florian Weimer / Red Hat Product Security Team
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
