[Cryptography] RNG design principles

[John Denker]

On 11/26/2016 12:42 AM, Ard Biesheuvel wrote:
> I have recently implemented early seeding of the kernel's entropy pool
> for ARM and arm64 UEFI systems, in a way that x86 should be able to
> reuse. The patches are queued up for inclusion in Linux v4.10 [0]
> 
> The seed is obtained from the firmware's implementation of
> EFI_RNG_PROTOCOL, which is usually implemented on top of some on-chip
> RNG peripheral (but it could be a chaoskey as well, once my buddy Leif
> completes the UEFI driver for it [1]). The UEFI firmware for VMs (OVMF
> for x86, ArmVirtQemu for ARM/arm64) also implements this protocol
> based on the virtio-rng device.
> 
> The seed is passed to the kernel via a UEFI configuration table, which
> is a standard mechanism for the firmware to expose information to the
> OS. This data is not visible outside of the kernel, unless it is
> explicitly exported.

Thanks!  That sounds like a big step in the right direction.
This is really important, because it is one of precious few
ways of getting randomness into the system /early enough/.

There remain a couple of points where it might be nice to get
some clarification:

What happens if there is /not/ some on-chip RNG peripheral, or
not one that the firmware knows about?

In particular, is it possible for *grub* to scribble into the
configuration table?  This is important, because what we face
is partly an interface plumbing problem.

  1) There are situations where it would be a big win to have
   grub pass a seed, taken from the grub configuration file,
   updated between one boot and the next via:
	grub-editenv /boot/grub/grubenv set randomseed=0:yBwrcLYCLept2GTvVyRQmnGikarfOmZ3

  2) There are situations where the best option is to literally
   roll the dice and feed a seed to grub by hand.
    2a) Passing it on the kernel command line is one option,
     which has some charm because grub already fully understands
     the command line.
    2b) Passing it via the EFI configuration table is also fine
     but might require changes to grub.  Note that changing grub
     may be easier than changing the kernel, so as soon as we get
     a kernel that knows what to do with the configuration table,
     this option (2b) might be the way to go.
	https://www.gnu.org/software/grub/manual/grub.html#Command_002dline-and-menu-entry-commands

  3) Any VM host "should" provide both a virtual RDRAND instruction
   and a virtual /dev/hrng, but if it doesn't, a fallback option is
   to send a seed to the client via grub.  VMs already know how to
   talk to grub.  I don't care whether this is done via the kernel
   command line or via some other grub feature.

   Another possibility is for the VM host to munge /boot/grub/grubenv
   directly, before firing up the guest machine, in which case this
   reduces to scenario (1).

This is a multi-piece puzzle.  Having one critical piece in place
increases the motivation to come up with the remaining pieces.