On Thu, May 1, 2014 at 3:46 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 05/01/2014 03:32 PM, Andy Lutomirski wrote: >> On Thu, May 1, 2014 at 3:28 PM, <tytso@xxxxxxx> wrote: >>> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote: >>>> >>>> I still don't see the point. What does this do better than virtio-rng? >>> >>> I believe you had been complaining about how complicated it was to set >>> up virtio? And this complexity is also an issue if we want to use it >>> to initialize the RNG used for the kernel text ASLR --- which has to >>> be done very early in the boot process, and where making something as >>> simple as possible is a Good Thing. >> >> It's complicated, so it won't be up until much later in the boot >> process. This is completely fine for /dev/random, but it's a problem >> for /dev/urandom, ASLR, and such. >> >>> >>> And since we would want to use RDRAND/RDSEED if it is available >>> *anyway*, perhaps in combination with other things, why not use the >>> RDRAND/RDSEED interface? >> >> Because it's awkward. I don't think it simplifies anything. >> > > It greatly simplifies discovery, which is a Big Deal[TM] in early code. I think we're comparing: a) cpuid to detect rdrand *or* emulated rdrand followed by rdrand to b) cpuid to detect rdrand or the paravirt seed msr/cpuid call, followed by rdrand or the msr or cpuid read this seems like it barely makes a difference, especially since (a) probably requires detecting KVM anyway. For the real kernel code, it's probably even closer to making no difference, since I don't think we'll want arch_get_random_long to use emulated rdrand. --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
