[Cryptography] RNG design principles
ard.biesheuvel at gmail.com
Sun Nov 27 07:18:49 EST 2016
(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 
>> 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 ). 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
> 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.
I think the command line should be avoided, for reasons you pointed
out yourself: it is copied around, and typically visible to
> 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).
> 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
More information about the cryptography