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

[John Gilmore]

> The raw access mode is disabled on production parts. This is because
> it would be an attack vector. Log into a VM in a cloud machine and
> put the RNG into raw mode and other processes in other VMs would
> then be getting unwhitened data while thinking they were getting the
> output of a CSPRNG (RdRand) or an ENRBG (RdSeed).

Hi David!  This is a bad reason to not allow raw access.  
You have confused the means with the end.

The problem *isn't* that raw access is available.  The problem is that
you defined a *mode bit* that makes reads of the Whitened device
produce data that was Raw rather than Whitened.  By setting that mode
bit, one program could violate another program's assumptions.  The
mode bit is the attack vector.  The raw access is not.

If you had merely not used a static mode bit for raw access, this
would not be an issue.  If e.g. you had two instructions, one for raw
and one for whitened; or if the raw data was available some other way
such as via a control register read, that would not cause any security
issue.  Intel actually did this for the RDSEED instruction -- which
gets around the final level of RDRAND (AES counter mode) but foolishly
didn't take this opportunity to provide a distinct path to read the
raw bits before the whitener.  They even took two shots over four
years to get this right, and still got it wrong.

	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.