Re: [PATCH] random: Move rand_initialize() earlier

[Theodore Y. Ts'o]

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 <keescook@xxxxxxxxxxxx>

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