Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1577297

Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()

From Theodore Ts'o <tytso@mit.edu>
Newsgroups linux.kernel
Subject Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()
Date 2017-02-09 05:20 +0100
Message-ID <t8On7-1bs-1@gated-at.bofh.it> (permalink)
References <t8Odr-187-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote:
> The new non-blocking system introduced in commit e192be9d9a30 ("random:
> replace non-blocking pool with a Chacha20-based CRNG") can under
> some circumstances report itself initialized while it still contains
> dangerously little entropy, as follows:
> 
> Approximately every 64th call to add_interrupt_randomness(), the "fast"
> pool of interrupt-timing-based entropy is fed into one of two places. At
> calls numbered <= 256, the fast pool is XORed into the primary CRNG state.
> At call 256, the CRNG is deemed initialized, getrandom(2) is unblocked,
> and reading from /dev/urandom no longer gives warnings.
> 
> At calls > 256, the fast pool is fed into the input pool, leaving the CRNG
> untouched.
> 
> The problem arises between call number 256 and 320. If crng_initialize()
> is called at this time, it will overwrite the _entire_ CRNG state with
> 48 bytes generated from the input pool.

So in practice this isn't a problem because crng_initialize is called
in early init.   For reference, the ordering of init calls are:

	"early",  <--- crng_initialize is here()
	"core",   <---- ftrace is initialized here()
	"postcore",
	"arch",
	"subsys",  <---- acpi_init is here()
	"fs",
	"device",  <---- device probing is here
	"late",

So in practice, call 256 typically happens **well** after
crng_initialize.  You can see where it is the boot messages, which is
after 2.5 seconds into the boot:

[    2.570733] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
[    2.570863] usbcore: registered new interface driver i2c-tiny-usb
[    2.571035] device-mapper: uevent: version 1.0.3
[    2.571215] random: fast init done  <-------------
[    2.571316] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: dm-devel@redhat.com
[    2.571678] device-mapper: multipath round-robin: version 1.1.0 loaded
[    2.571728] intel_pstate: Intel P-state driver initializing
[    2.572331] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3
[    2.572462] intel_pstate: HWP enabled
[    2.572464] sdhci: Secure Digital Host Controller Interface driver

When is crng_initialize() called?  Sometime *before* 0.05 seconds into
the boot on my laptop:

[    0.054529] ftrace: allocating 29140 entries in 114 pages

> In short, the situation is:
> 
> A) No usable hardware RNG or arch_get_random() (or we don't trust it...)
> B) add_interrupt_randomness() called 256-320 times but other
>    add_*_randomness() functions aren't adding much entropy.
> C) then crng_initialize() is called
> D) not enough calls to add_*_randomness() to push the entropy
>    estimate over 128 (yet)
> E) getrandom(2) or /dev/urandom used for something important
> 
> Based on a few experiments with VMs, A) through D) can occur easily in
> practice. And with no HDD we have a window of about a minute or two for
> E) to happen before add_interrupt_randomness() finally pushes the
> estimate over 128 on its own.

How did you determine when crng_initialize() was being called?  On a
VM generally there are fewer interrupts than on real hardware.  On
KVM, for I see the random: fast_init message being printed 3.6 seconds
into the boot.

On Google Compute Engine, the fast_init message happens 52 seconds into the
boot.

So what VM where you using?  I'm trying to figure out whether this is
hypothetical or real problem, and on what systems.

	     	     	      	     - Ted

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] random: Don't overwrite CRNG state in crng_initialize() Alden Tondettar <alden.tondettar@gmail.com> - 2017-02-09 05:10 +0100
  Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Theodore Ts'o <tytso@mit.edu> - 2017-02-09 05:20 +0100
    Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Alden Tondettar <alden.tondettar@gmail.com> - 2017-02-09 09:20 +0100
      Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Theodore Ts'o <tytso@mit.edu> - 2017-02-09 19:40 +0100
      Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Theodore Ts'o <tytso@mit.edu> - 2017-02-09 20:10 +0100
  Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-09 07:50 +0100
    Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Alden Tondettar <alden.tondettar@gmail.com> - 2017-02-09 10:10 +0100
      Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Stephan Müller <smueller@chronox.de> - 2017-02-09 10:30 +0100
      Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-02-09 10:30 +0100

csiph-web