Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 22 Mar 2022 20:50:41 -0600
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     David Laight <David.Laight@ACULAB.COM>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        Theodore Ts'o <tytso@mit.edu>, Jann Horn <jannh@google.com>
Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast
 init
Message-ID: <YjqLAWbZ8K7eg3Fw@zx2c4.com>
References: <20220322191436.110963-1-Jason@zx2c4.com>
 <6716f3ffefae4ed8b5fd332bfcca8a9a@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <6716f3ffefae4ed8b5fd332bfcca8a9a@AcuMS.aculab.com>
Precedence: bulk

Hi David (and Linus),

On Tue, Mar 22, 2022 at 8:16 PM David Laight <David.Laight@aculab.com> wrote:
> Never mind scripts that try to immediately save a new seedfile [1].
>
> What about code run by later startup scripts that wants random numbers.
> They really do want the seedfile data to be used.
> If it isn't used then they are likely to get very weak random numbers.
>
> You can't really expect startup scripts to be issuing ioctl requests.

To be clear, this "expect[ation]" of yours is very much a new
expectation. Crediting bits has required an ioctl since forever. Those
shell scripts have been broken forever. The proposal here is to add new
behavior to support those old broken shell scripts.

Fortunately, it seems sort of fixable. But only sort of. There are also
a lot of complications, as detailed above. Part of it is that some
people use /dev/urandom writes expecting it not to credit, while others
use that and then later manually credit it with the ioctl. Both of those
in general seem like not a very good interface for seeding the rng. The
correct interface to use is RNDADDENTROPY, which takes both the data and
whether it should be credited, since then the kernel knows what the
intentions are and can do something smart with it. Barring that
knowledge, we're in this vague middle ground where it's unclear what the
user intends to do.

"But I want my shell scripts to work, even if they have never worked,"
you fairly protest. I'll do my best here to figure something out, but
note that introducing sane behavior to /dev/urandom writes might imply
breaking compatibility with the behavior /dev/urandom writes have always
had in the past. So the "perfect" solution for a shell script seeding
interface might prove elusive, and we'll be left with something merely,
"not terrible."

However, if you do think you have a "perfect" solution that takes into
account all these concerns and doesn't break any prior contracts, please
do pipe up.

Two more thoughts, also for Linus' consideration:

- Had we not needed to revert the /dev/urandom + /dev/random unification
  patch, we wouldn't be facing this problem. So a last minute creative
  solution to save that effort would be quite welcome. I'm not
  optimistic about us finding that right away, but if a lightbulb goes
  off, I'd be quite happy.

- Since these seeding shell scripts have always been broken, because
  this is how the rng has always been, rather than trying to bolt on a
  very imperfect fix in the kernel for something that never worked
  right, we could suggest shell scripts take the path that I implemented
  for systemd:
  https://github.com/systemd/systemd/commit/da2862ef06f22fc8d31dafced6d2d6dc14f2ee0b
  In shell, this would look like:

    #!/bin/bash
    cat seedfile > /dev/urandom
    { cat seedfile; head -c 32 /dev/urandom; } | sha256sum | cut -d ' ' -f 1 > seedfile
 
  This seems better in nearly every way to trying to retroactively fix it
  in the kernel by changing the semantics of an extremely old interface.
  The more I think about it, the more I'm inclined to go with this "do
  nothing" approach. Open to hearing your thoughts though.

Jason