On Thu, Oct 11, 2018 at 03:54:21PM -0700, Kees Cook wrote: > Right now rand_initialize() is run as an early_initcall(), but it only > depends on timekeeping_init() (for mixing ktime_get_real() into the > pools). However, the call to boot_init_stack_canary() for stack canary > initialization runs earlier, which triggers a warning at boot: > > random: get_random_bytes called from start_kernel+0x357/0x548 with crng_init=0 > > Instead, this moves rand_initialize() to after timekeeping_init(), and moves > canary initialization here as well. > > Note that this warning may still remain for machines that do not have > UEFI RNG support (which initializes the RNG pools durting setup_arch()), > or for x86 machines without RDRAND (or booting without "random.trust=on" > or CONFIG_RANDOM_TRUST_CPU=y). > > Signed-off-by: Kees Cook <keesc...@chromium.org>
This seems reasonable to me. Were you hoping to get this in for -rc8? It looks sane, and I don't see any _obvious_ unintended consequences of such a change, but it's rather late in the development cycle, and it isn't regression fix. My druthers would be wait until -rc2, as a minor low-risk improvement that goes in after the merge window, although some people are of the belief that -rc2 should be a strict feature freeze delimiter. My personal opinion is no major feature changes except during the merge window, and we go into bug-fix only mode after -rc4, and by -rc6 it's regression and major security fixes only. (This is however not a universally held opinion; see the "bug-introducing patches" thread which Sasha started on the ksummit-discuss thread.) - Ted