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

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

[Arnd Bergmann]

On Fri, Oct 12, 2018 at 12:54 AM Kees Cook <keescook@chromium.org> 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 during 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@chromium.org>
> ---
> Alternatively, ktime_get_real() could get mixed into the pools after
> timekeeping_init(), and rand_initialize() could be run MUCH early,
> like after setup_arch()...

I wonder if mixing in ktime_get_real() is flawed to start with:
This depends on read_persistent_clock64() actually returning
a meaningful time, but in many cases it does not; x86 being
a notable exception.

We have three ways of setting the initial time:

* At early boot using read_persistent_clock64(). This may read
  the time from the hypervisor (if any), and on some older
  architectures that have a custom RTC abstraction, it
  reads from the RTC directly. We generally move away from
  the RTC method in favor of the proper rtc class interfaces
  (see below)

* At late_initcall time, in rtc_hctosys(). If an RTC driver has
  been loaded successfully at this time, it will be read from
  there. We also move away from this.

* From user space, which reads the RTC time or NTP,
  and then sets the system time from that.

The latter two end up in do_settimeofday64(), but there
is no mixing in of the time into the random seed that I can
see, and it's not clear whether there should be (it
can be called with arbitrary times from user space,
provided CAP_SYS_TIME permissions).

       Arnd

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

[Theodore Y. Ts'o]

On Fri, Oct 12, 2018 at 10:42:39AM +0200, Arnd Bergmann wrote:
> I wonder if mixing in ktime_get_real() is flawed to start with:
> This depends on read_persistent_clock64() actually returning
> a meaningful time, but in many cases it does not; x86 being
> a notable exception.
> 
> We have three ways of setting the initial time:
> 
> * At early boot using read_persistent_clock64(). This may read
>   the time from the hypervisor (if any), and on some older
>   architectures that have a custom RTC abstraction, it
>   reads from the RTC directly. We generally move away from
>   the RTC method in favor of the proper rtc class interfaces
>   (see below)
> 
> * At late_initcall time, in rtc_hctosys(). If an RTC driver has
>   been loaded successfully at this time, it will be read from
>   there. We also move away from this.
> 
> * From user space, which reads the RTC time or NTP,
>   and then sets the system time from that.
> 
> The latter two end up in do_settimeofday64(), but there
> is no mixing in of the time into the random seed that I can
> see, and it's not clear whether there should be (it
> can be called with arbitrary times from user space,
> provided CAP_SYS_TIME permissions).

I think it adds some real value (although perhaps small) in the first
two cases.  In all of the cases, though, since we don't add any
entropy credit, it doesn't hurt to mix it in --- this is the same
argument why it's fine that /dev/[u]random can be world-writeable.
Mixing in user-controlled data is harmless, and if it's not visible to
a remote attacker, it can be helpful.

						- Ted