[Cryptography] Use of RDRAND in Haskell's TLS RNG?

Stephan Müller smueller at chronox.de
Mon Nov 28 03:09:54 EST 2016

Am Sonntag, 27. November 2016, 22:06:02 CET schrieb John Gilmore:

Hi John,

> PS: Don't I recall that a VM kernel can violate the specs of RdRand or
> RdSeed anyway, by disabling the instruction and emulating it?  As I
> recall, this was explained as a way to make "dualed" or
> "i-tell-you-three-times" systems produce the exact same random
> numbers, so they wouldn't take divergent execution paths.  But of
> course including a way to make the CPU trap when it encounters the
> unprivileged RDRAND instruction makes RDRAND into a "virtual random
> number" facility that causes the same "attack vector" problem.  A
> virtual machine can't trust the random numbers that the RdRand
> instruction gives it, because the VM kernel can subvert the
> instruction.  So not only did you fail to provide a secure RNG for
> virtual machines, but then you failed to allow raw access due to
> claiming to avoid an attack scenario that your architecture can't
> avoid anyway.
> Citation:
> http://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-> ia-32-architectures-software-developer-manual-325462.pdf
> The RDRAND instruction description on page 1661 doesn't say that the
> VM kernel can trap upon its execution -- but another part of the
> manual does.  See page 3738 under "VMX Non-Root Operation":
>   RDRAND. The RDRAND instruction causes a VM exit if the "RDRAND
>   exiting" VM-execution control is 1.
> and page 4468 of the PDF under "Enclave Operation" for the details.

Using a 6-line patch against KVM which traps RDRAND/RDSEED and returns 0 to a 
guest when the guest uses RDRAND/RDSEED, the VM-exit functionality is 


More information about the cryptography mailing list