On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin <h...@zytor.com> 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 > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
