linux-kernel - Re: [PATCH] random: Move rand

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 12 Oct 2018 10:29:02 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Kees Cook <keescook@...omium.org>
Cc:     linux-kernel@...r.kernel.org, Laura Abbott <labbott@...hat.com>,
        Daniel Micay <danielmicay@...il.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        "Tobin C. Harding" <me@...in.cc>, Arnd Bergmann <arnd@...db.de>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] random: Move rand_initialize() earlier

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