Populate /chosen/rng-seed with the HWRNG

[tc287]

Linux supports adding "bootloader randomness" from the device tree via /chosen/rng-seed. This happens in early_init_dt_scan_chosen() just after the command line is copied from /chosen/bootargs, and has several advantages over other methods of adding HWRNG entropy to the kernel entropy pool (mainly that it happens very early in the boot process).

The bootloader (probably start*.elf) should populate /chosen/rng-seed with ~64 bytes from the HWRNG. (I assume it does not currently do this, because start*.elf contains the string /chosen/kaslr-seed but not rng-seed.)

Notes:

• The fix for No firmware support for linux kernel address randomization #694 (which populates /chosen/kaslr-seed with 8 bytes from the HWRNG) can probably be used as a guide. (I don't know if kaslr-seed is only populated on 64-bit boots, but we would want to populate rng-seed on both 32-bit and 64-bit boots.)
• The size is somewhat arbitrary, but 64 bytes was originally proposed in the kernel patch thread and used in ChromiumOS (albeit both by the same author), and is twice the key size of Linux's CRNG (ChaCha20) which gives a comfortable margin even if the HWRNG output is slightly biased.
• Unfortunately there is no feedback that this was successful other than the property being removed.
  • I have not found a way to enable feedback, since this happens before the kernel command line is parsed, so tracing with tp_printk trace_event=random:mix_pool_bytes does not catch it. (Perhaps there is a way to enable it in the compile-time config?).
  • If there's a way to read the raw FDT, then that could be used to confirm that /chosen/rng-seed was overwritten with FDT_NOP.
  • The simplest way is to compare behaviour of /chosen/rng-seed with a misspelling (e.g. /chosen/rng-seee) which would not be removed.
  • I'm not sure why /chosen/kaslr-seed is not removed, since it leaks KASLR parameters to userspace. (It's removed/rewritten for kexec but not when setting up kaslr.)
• Documentation for this DT property appears to be at https://github.com/devicetree-org/dt-schema/blob/19d754e9e2b6b319bbfd98efa26c1578e61a088a/schemas/chosen.yaml#L55 (the kernel patch thread suggests Documentation/devicetree/bindings/chosen.txt is deprecated).

System

System Information
------------------

Raspberry Pi 400 Rev 1.0
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Raspberry Pi reference 2021-05-07
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 071d3956353f2be964d2d337d3b123f1872b7f53, stage2

Linux <SNIP> 5.10.17-v8+ #1414 SMP PREEMPT Fri Apr 30 13:23:25 BST 2021 aarch64 GNU/Linux
Revision	: c03130
Serial		: <SNIP>
Model		: Raspberry Pi 400 Rev 1.0
Throttled flag  : throttled=0x0
Camera          : supported=0 detected=0

Videocore information
---------------------

Apr 30 2021 13:45:52 
Copyright (c) 2012 Broadcom
version d7f29d96450abfc77cd6cf011af1faf1e03e5e56 (clean) (release) (start)

alloc failures:     0
compactions:        0
legacy block fails: 0

<SNIP>

[pelwell]

There is an internal patch open for review that adds the rng-seed property. Assuming no problems are found it should be merged in the next few days, at which point it can begin its journey to users.

[pelwell]

There is a new firmware available from this repo and installable with sudo rpi-update that adds /chosen/rng-seed. You might want to back up any valuable data before updating because like all rpi-update releases this will have had very little testing so far.

[P33M]

I believe the kernel config option CONFIG_RANDOM_TRUST_BOOTLOADER is required for Linux to, well, trust the rng-seed value. If I boot with latest rpi-update firmware, one of the early lines printed out is [ 0.000000] random: get_random_bytes called from start_kernel+0x3bc/0x580 with crng_init=0 which implies the CRNG has no entropy available. If I rebuild with CONFIG_RANDOM_TRUST_BOOTLOADER=y then this line has a crng_init=1 value, and the message random: fast init done appears before the get_random_bytes message, and very early.

[pelwell]

CONFIG_RANDOM_TRUST_BOOTLOADER=y is now set by our defconfigs.

[tc287]

Thanks for the quick fix!

I believe the kernel config option CONFIG_RANDOM_TRUST_BOOTLOADER is required for Linux to, well, trust the rng-seed value.

Sort-of: AIUI CONFIG_RANDOM_TRUST_BOOTLOADER only affects the kernel's entropy estimate; enabling it (mostly) just means /dev/random will unblock sooner and "fast init done" will happen sooner. (Probably worth doing simply for confirmation that it's working, since add_bootloader_randomness doesn't printk.)

[pelwell]

Probably worth doing simply for confirmation that it's working, since add_bootloader_randomness doesn't printk.

Already done.