[Cryptography] RNG design principles

[Ard Biesheuvel]

(I got a moderator bounce so the list may not have received the
message John is replying to. Adding Ted and Leif to cc)

2016-11-26 18:20 GMT+00:00 John Denker <jsd at av8n.com>:
> 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?
>

Then we are simply in the situation we were before the patches. Note
that add_device_randomness does not increase the internal entropy
estimate maintained by the randomness subsystem

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

Indeed. The EFI aware version of GRUB (which is the only option on
ARM/arm64, and the most widely used option on x86 AFAIK) can easily
install such a configuration table, either based on a GRUB environment
variable, or based on bits its receives from the EFI_RNG_PROTOCOL
itself.

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

I think the command line should be avoided, for reasons you pointed
out yourself: it is copied around, and typically visible to
unprivileged users.

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

I see little reason to deviate from the above for VMs

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

Indeed.

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

OK, so bottom line is that GRUB needs to install the RNG seed config table if
- a randomseed env var is present (and it probably needs to clear it as well)
- (on x86) the firmware implements EFI_RNG_PROTOCOL