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

[Theodore Ts'o]

On Mon, Feb 03, 2014 at 01:55:57PM -0700, John Denker wrote:
> 
>   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

Linux kernels newer than 3.3 (released about two years ago) will use
arch_get_random_long/int() in some way.  The
arch_get_random_long/int() functions are wired up to RDRAND on x86
systems that have it.  We use a generic name so we can support other
CPU's that might have a purpose built hwrng.

>    However, AFAICT there is no place in the kernel that makes use of the
>    /dev/hwrng device, even if it is available.

Yes; that's the job of userspace rngd daemon.  The idea is that if you
are using some random home-built which you've wired up into a usb
drive, it might have some catastrophic failure mode, and it's better
to have a userspace daemon which can do some sanity checks on the
entropy source before we use it.

It's possible that we could have the kernel automatically use the
entropy source from /dev/hwrng but not give any entropy credit.  My
only concern is that sometimes the /dev/hwrng device may use extra
battery when you access it, so whether we did this would have to be
configurable, and perhaps the default should be keyed on whether we
are running on battery or not.

(Basically, there's an assumption that arch_get_random_long/int() is
essentially free from a power perspective, and it's competently
implemented such that we don't need to worry about doing any sanity
checking.  OTOH, we also aren't giving any entropy credit for RDRAND,
either.  People who want the RDRAND source to be counted as entropy
credit will need to use rngd, since that's a policy decision I didn't
want to leave hard-wired into the kernel.  

Also, I'd note that vast majority of the deployed Linux systems don't
have an extrnal entropy source which can be accessed via /dev/hwrng.)

>    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.

No.  Bad idea.  Programs should use /dev/urandom for session keys or
if they can not afford to block, and /dev/random if they are
generating a high value or long-term private key.

>    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.

This is why it's actually better to tell programs to use
/dev/[u]random, since that way you always get environmental noise
mixed in.  Using /dev/[u]random also makes your program portable to
other operating systems and othe platforms that may not have RDRAND,
but may have some other high frequency counter we can use in
combination with external events.  (For example, on MIPS systems there
is a DRAM refresh counter we can use, etc.)

						- Ted