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

[James A. Donald]

On 2014-02-04 06:55, John Denker wrote:
> -----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?

On the physical machine, all the philosophical problems about real 
randomness go away, so the ring 0 layer can collect a 160 bits of true 
randomness, and be pretty sure it really has collected 160 bits of real 
randomness.  The physical machine has true access to physical things, 
which are unarguably truly random.

It can then emulate the rdrand instruction and provide pseudo random 
data from a seed unknowable to the attacker, which is, for a sufficient 
seed, sufficiently inaccessible to the attacker, as good as true random.

So such an emulated rdrand instruction would be wonderful, would end all 
this debate.