The normal CPUID bit is unset I believe. On May 1, 2014 12:02:49 PM PDT, Andy Lutomirski <[email protected]> wrote: >On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin <[email protected]> wrote: >> On 05/01/2014 11:53 AM, Andy Lutomirski wrote: >>> >>> A CPUID leaf or an MSR advertised by a CPUID leaf has another >>> advantage: it's easy to use in the ASLR code -- I don't think >there's >>> a real IDT, so there's nothing like rdmsr_safe available. It also >>> avoids doing anything complicated with the boot process to allow the >>> same seed to be used for ASLR and random.c; it can just be invoked >>> twice on boot. >>> >> >> At that point we are talking an x86-specific interface, and so we >might >> as well simply emulate RDRAND (urandom) and RDSEED (random) if the >CPU >> doesn't support them. I believe KVM already has a way to report >CPUID >> features that are "emulated but supported anyway", i.e. they work but >> are slow. > >Do existing kernels and userspace respect this? If the normal bit for >RDRAND is unset, then we might be okay, but, if not, then I think this >may kill guest performance. > >Is RDSEED really reasonable here? Won't it slow down by several >orders of magnitude? > >> >>> What's the right forum for this? This thread is probably not it. >> >> Change the subject line? > >:) > >> >> -hpa >> >>
-- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
