Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 24 Mar 2022 12:28:56 -0400
From:   "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast
 init
To:     Jann Horn <jannh@google.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        Guenter Roeck <linux@roeck-us.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Theodore Ts'o <tytso@mit.edu>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
References: <20220322191436.110963-1-Jason@zx2c4.com>
        <1648009787.fah6dos6ya.none@localhost>
        <CAHmME9rsvxczJrhPwRX6nyrh9NB2AuJqkEKrTLx-G-T1J6_czQ@mail.gmail.com>
        <CAHmME9ovJpdcuuZhNKrOTUc8XvKDDdC+axhAmOD9iESnRR7JqA@mail.gmail.com>
In-Reply-To: <CAHmME9ovJpdcuuZhNKrOTUc8XvKDDdC+axhAmOD9iESnRR7JqA@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <1648138746.2zrnsqdlu7.none@localhost>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Excerpts from Jason A. Donenfeld's message of March 23, 2022 11:18 pm:
> Hi all,
>=20
> [...]
>
> In light of that conclusion, I'm going to work with every userspace
> downstream I can find to help them fix their file-based seeding, if it
> has bugs. I've started talking with the buildroot folks, and then I'll
> speak with the OpenRC people (being a Gentoo dev, that should be easy
> going). Systemd does the right thing already.
>=20
> I wrote a little utility for potential inclusion in
> busybox/util-linux/whatever when it matures beyond its current age of
> being half hour old:
> - https://git.zx2c4.com/seedrng/about/
> - https://git.zx2c4.com/seedrng/tree/seedrng.c
> So I'll see what the buildroot people think of this and take it from ther=
e.
>=20
> The plus side of doing all this is that, if the efforts pan out, it
> means there'll actually be proper seeding on devices that don't
> currently do that, which then might lead to a better ecosystem and
> less boot time blocking and all that jazz.
>=20
> Jason
>=20

The issue, in systemd developers' opinion, is that counting seed file=20
towards entropy initialization potentially causes repeated RNG output if=20
a system is cloned without resetting the seed file. This is discussed at=20
length in https://github.com/systemd/systemd/pull/4513. A few years ago,=20
I wrote most of a program to check machine ID, disk ID, DMI ID, and some=20
other things in order to avoid this issue. Since then, systemd decided=20
to store the random seed in EFI variables, I assume on the basis that=20
machine cloning typically does not clone the EFI variables? In my=20
opinion, since the same argument applies to machine ID, ssh keys, and=20
any other persistent cryptographic (or even non-cryptographic) material,=20
this falls outside the scope of random seeding and into a general=20
machine cloning "sysprep"-like utility.

Cheers,
Alex.