[Cryptography] cheap sources of entropy

[Theodore Ts'o]

On Sun, Feb 02, 2014 at 02:02:15PM +1000, James A. Donald wrote:
> Disk read completes at a time that depends on disk turbulence.  The
> real machine now has to do something with the data.  Letting it pile
> up to the next scheduling quantum is going to result in the disk
> head passing over the next disk sector, resulting in a painfully
> slow read.  So, unless your real machine is crazy inefficient, it is
> going to immediately wake the consumer of the data at a time that
> depends on disk turbulence, in the hope that it can read sectors
> sequentially as the platter spins.

Jerry Leichter has already explained why with track buffers this isn't
a concern.  In addition to that, modern file systems don't send read
requests one sector at a time, because of controller overhead; we will
try to read, and write large extents of data at a time --- preferably,
64k, or even several megabytes, at a time.

Your conception how disk drivers had to optimize for sectors going
under the disk head was true back in the era of the Apple II and the
TRS-80's (and in my first computer, which was a PDP-8/i with a DF32
fixed-head disk drive which stored 32k 12-bit words on a single-sided
12" platter).  But that hasn't been true for quite some time.

In *addition*, once the host OS gets the data requested by the guest
OS, the "wakeup()" function does *not*, in general, immediately wake
up the guest OS.

Most VM providers, not being Mafia fronts trying to launder money,
prefer not to lose money and go out of business, which means that
their machines are not idle, but in fact there are dozens, if not
hundreds of VM's running on each physical host.  That means on a disk
interrupt, the wakeup() function puts the process (such as the guest
VM) on a linked list of processes that should be run the next time
there is a free CPU and their turn is up.  This *can* happen due to
all other guest OS's getting blocked on I/O, but if you have
processes/VM's which are CPU bound, they will get to run until their
scheduling quanta runs out, which is measured in units of 100HZ clock
ticks.  Which is why you can see quantization effects.

The bottom line is that when the guest OS gets the virtualized disk
interrupt delivered to it is going to be based not on "disk
turbulence" (the theoretical underpinning of which was a paper written
in '94, and disk drive technologies have changed a wee bit since
then), but based on when other VM's might be blocking, or when some
other cpu-bound guest OS gives up its CPU on a clock tick boundary.

Now, all of this might not be predictable to an outside observer who
doesn't have full information about the internal state of the Host OS,
and all of the guest OS's running on it.  But it's not based on
chaotic air patterns, but rather something else.

Is it good enough?  Maybe.  My preference, as others have suggested,
is to mix in something purpose built, such as RDRAND, and if that has
been backdoored somehow, either by the NSA or the MSS, to also mix in
as much environmental noise as you can get.  Belt and suspenders....

   		      	       	       - Ted