linux-kernel - Re: [PATCH v1] random: block in /dev/urandom

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:   Tue, 22 Mar 2022 12:19:16 -0600
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-arch@...r.kernel.org, Dinh Nguyen <dinguyen@...nel.org>,
        Nick Hu <nickhu@...estech.com>,
        Max Filippov <jcmvbkbc@...il.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        "David S . Miller" <davem@...emloft.net>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Michal Simek <monstr@...str.eu>,
        Borislav Petkov <bp@...en8.de>, Guo Ren <guoren@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Joshua Kinard <kumba@...too.org>,
        David Laight <David.Laight@...lab.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Eric Biggers <ebiggers@...gle.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Lennart Poettering <mzxreary@...inter.de>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH v1] random: block in /dev/urandom

Hi Guenter,

On Tue, Mar 22, 2022 at 10:56:44AM -0700, Guenter Roeck wrote:
> Everything - including the various root file systems - is at
> git@...hub.com:groeck/linux-build-test.git. Look into rootfs/ for the
> various boot tests. I'll be happy to provide some qemu command lines
> if needed.

Thanks. It looks like the "problem" is with this shell script:

  init_rng() {
    if check_file_size; then
      printf 'Initializing random number generator: '
      dd if="$URANDOM_SEED" bs="$pool_size" of=/dev/urandom count=1 2> /dev/null
      status=$?
      if [ "$status" -eq 0 ]; then
        echo "OK"
      else
        echo "FAIL"
      fi
      return "$status"
    fi
  }

  save_random_seed() {
    printf 'Saving random seed: '
    if touch "$URANDOM_SEED" 2> /dev/null; then
      old_umask=$(umask)
      umask 077
      dd if=/dev/urandom of="$URANDOM_SEED" bs="$pool_size" count=1 2> /dev/null
      status=$?
      umask "$old_umask"
      if [ "$status" -eq 0 ]; then
        echo "OK"
      else
        echo "FAIL"
      fi
    else
      status=$?
      echo "SKIP (read-only file system detected)"
    fi
    return "$status"
  }

  case "$1" in
    start|restart|reload)
      # Carry a random seed from start-up to start-up
      # Load and then save the whole entropy pool
      init_rng && save_random_seed;;

This code is actually problematic for a number of reasons. (And Linus,
I'm not saying "userspace is wrong" to justify breaking it or something,
don't worry.)

The first `dd if="$URANDOM_SEED" bs="$pool_size" of=/dev/urandom count=1`
will write the seed into the input pool, but:

  - It won't credit the entropy from that seed, so the pool won't
    actually initialize. (You need to use the ioctl to credit it.)
  - Because the pool doesn't initialize, subsequent reads from
    /dev/urandom won't actually use that seed.

The first point is why we had to revert this patch. But the second one
is actually a bit dangerous: you might write in a perfectly good seed to
/dev/urandom, but what you read out for the subsequent seed may be
complete deterministic crap. This is because the call to write_pool()
goes right into the input pool and doesn't touch any of the "fast init"
stuff, where we immediately mutate the crng key during early boot.

As far as I can tell, this has been the behavior for a really long time,
making the above innocuous pattern a pretty old thing that's broken. So
I could perhaps say, "this behavior is so old now, that your userspace
code is just plain broken," but I think I might actually have a very
quick unobtrusive fix for this. I'll mull some things over for rc2 or
later in rc1.

But, anyway, this only fixes the second point mentioned above. The first
one -- which resulted in the revert -- remains a stumper for now.

Jason