On Wed, Jul 16, 2014 at 12:36 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > Il 16/07/2014 09:10, Daniel Borkmann ha scritto: > >> On 07/16/2014 08:41 AM, Gleb Natapov wrote: >>> >>> On Tue, Jul 15, 2014 at 07:48:06PM -0700, Andy Lutomirski wrote: >>>> >>>> virtio-rng is both too complicated and insufficient for initial rng >>>> seeding. It's far too complicated to use for KASLR or any other >>>> early boot random number needs. It also provides /dev/random-style >>>> bits, which means that making guest boot wait for virtio-rng is >>>> unacceptably slow, and doing it asynchronously means that >>>> /dev/urandom might be predictable when userspace starts. >>>> >>>> This introduces a very simple synchronous mechanism to get >>>> /dev/urandom-style bits. >>> >>> >>> Why can't you use RDRAND instruction for that? >> >> >> You mean using it directly? I think simply for the very same reasons >> as in c2557a303a ... > > > No, this is very different. This mechanism "provides no guarantee that the > result contains any actual entropy". In fact, patch 3 adds a call to the > new arch_get_slow_rng_u64 just below a call to arch_get_random_lang aka > RDRAND. I agree with Gleb that it's simpler to just expect a relatively > recent processor and use RDRAND. > > BTW, the logic for crediting entropy to RDSEED but not RDRAND escapes me. > If you trust the processor, you could use Intel's algorithm to force > reseeding of RDRAND. If you don't trust the processor, the same paranoia > applies to RDRAND and RDSEED. > > In a guest you must trust the hypervisor anyway to use RDRAND or RDSEED, > since the hypervisor can trap it. A malicious hypervisor is no different > from a malicious processor. > This patch has nothing whatsoever to do with how much I trust the CPU vs the hypervisor. It's for the enormous installed base of machines without RDRAND. hpa suggested emulating RDRAND awhile ago, but I think that'll unusably slow -- the kernel uses RDRAND in various places where it's expected to be fast, and not using it at all will be preferable to causing a VM exit for every few bytes. I've been careful to only use this in the guest in places where a few hundred to a few thousand cycles per 64 bits of RNG seed is acceptable. > In any case, is there a matching QEMU patch somewhere? What QEMU change is needed? I admit I'm a bit vague on how QEMU and KVM cooperate here, but there's no state to save and restore. I guess that QEMU wants the ability to turn this on and off for migration. How does that work? I couldn't spot the KVM code that allows this type of control. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
