[Cryptography] request for consideration: VM guest entropy: specific constructive suggestions

[John Denker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/02/2014 11:22 PM, Bill Stewart wrote:
> 
> I'm mainly worried about the "new virtual machine, cloned from a
> standard image" case, which needs to set up ssh keys, ssl keys, and
> seed /dev/random before it's ready to deal with the rest of the
> world in ways that would give it some more entropy to work with.

That is indeed an interesting thing to "worry" about.

The question arises, will the "worrying" be limited to feckless
hand-wringing, or are we "worried" enough to actually do something?

Specifically:

  Qemu already knows how to provide the guest with a virtual /dev/hwrng
   device ... it's just not the default.  References:
      http://wiki.qemu.org/Features-Done/VirtIORNG
      https://www.kernel.org/doc/Documentation/hw_random.txt

  Suggestion #1:  Make it the default, for security reasons.

==============

  There is code in the linux kernel to check for the availability of the
   RDRAND instruction
     http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/include/asm/archrandom.h
   and some versions of /dev/random seem to know about this:
     http://git.kernel.org/cgit/linux/kernel/git/tytso/random.git/tree/drivers/char/random.c#n940
   However, AFAICT there is no place in the kernel that makes use of the
   /dev/hwrng device, even if it is available.

   Suggestion #2:  On hardware where a satisfactory RDRAND instruction is 
    not native, one could teach qemu to trap and emulate this instruction.
    This looks like far and away the path of least resistance for introducing 
    effective randomness into guest systems.

   Tangential remark:  There are some hard feelings about the native RDRAND 
    instruction, due to lack of transparency as to its implementation.  One 
    could argue that the emulated version might actually be /better/ in terms
    of trust and transparency.

===========================================================

So, here's the action item:

Do we have consensus on this list that the foregoing suggestions are 
reasonable?  They obviously don't solve all the world's problems, but
can they be considered cost-effective steps in the right direction?

Can anybody think of any improvements that would reduce the barrier to
adoption?

  Actually, I can think of about a dozen improvements, but in the spirit
  of not making the perfect the enemy of the good, I hesitate to mention
  them.  It would be nice to get /something/ reasonable deployed, and
  then make incremental improvements.

The first step is to get consensus within the crypto/security community.
Then we can bring the qemu developers into the discussion.

Comments?  Questions?  Suggestions?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIVAwUBUvACXPO9SFghczXtAQJgvhAArAUxZ9yXb7ee5OClHDTjS1uH2LbrRPiF
deSywXenfpP+eYH4Qpitgkd6IaHoMvkH7fNoTGqcNB+t4oNGy6/BqOoGEuhI+vo5
Ar7lpwIykjVrRgaZv8Rfrbo+or0kbi0T8AFoqQKEOGETa5WzRfZq5kaPogj7pYP/
v90UgKTFLrHcSu5tP1pcGXH4sonSA08l9gJgQHlJhI0kEAKTCt3BByeMYR4J3W7m
Flw9nJNy2rOWbXaqHJ1Ai3vlYAc4bhTxNVWtRITaV9iBNaUzu0ffDuSv8ul3IcTJ
v7WXmmsUBhu5PcMMgvPzwyxIafeJd8FZZlj7tweI2Pj/MIiZOI88+VUc17dzQb+k
Y4wJJzVDx0PlQH7ZmEmd9c4vseSuYQ6u/XUbHYNhU9F+1sdQWT2KAhDGIY5NAwO7
at7zxKEFZ1F9OAMbvqe2fMJfRjWqejHm3ahGikeniH9j+ibr6//5iyBZ7s0jCfi6
pnxoubkch/Jf8dAaFITlgV4xjkyKjCkS71a1Tn9An90Wm3PC+IZbKdcj2tf7hC2o
OV1S70YnjxgZqHWapH2tKAgOUOu1rMM1+El3wPA3bkaSMOi3LYyNO8FfsBDKr1zI
mggruuqQuIV14XdoQ4Jw19esHt8nipFyRgB9YkEdNGT9LeDUltHqO+uRBaGmLWyL
S7VFL/jo7jQ=
=RVtr
-----END PGP SIGNATURE-----