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:   Thu, 24 Mar 2022 15:03:50 -0400
From:   "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast
 init
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     Jann Horn <jannh@google.com>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        LKML <linux-kernel@vger.kernel.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Theodore Ts'o <tytso@mit.edu>
References: <20220322191436.110963-1-Jason@zx2c4.com>
        <1648009787.fah6dos6ya.none@localhost>
        <CAHmME9rsvxczJrhPwRX6nyrh9NB2AuJqkEKrTLx-G-T1J6_czQ@mail.gmail.com>
        <CAHmME9ovJpdcuuZhNKrOTUc8XvKDDdC+axhAmOD9iESnRR7JqA@mail.gmail.com>
        <1648138746.2zrnsqdlu7.none@localhost> <YjyoaEZLb+GzxJFT@zx2c4.com>
In-Reply-To: <YjyoaEZLb+GzxJFT@zx2c4.com>
MIME-Version: 1.0
Message-Id: <1648148400.ytc07g7pbi.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 24, 2022 1:20 pm:
> Hi Alex,
>=20
> On Thu, Mar 24, 2022 at 10:29 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> w=
rote:
>> The issue, in systemd developers' opinion, is that counting seed file
>> towards entropy initialization potentially causes repeated RNG output if
>> a system is cloned without resetting the seed file. This is discussed at
>> length in https://github.com/systemd/systemd/pull/4513. A few years ago,
>> I wrote most of a program to check machine ID, disk ID, DMI ID, and some
>> other things in order to avoid this issue. Since then, systemd decided
>> to store the random seed in EFI variables, I assume on the basis that
>> machine cloning typically does not clone the EFI variables? In my
>> opinion, since the same argument applies to machine ID, ssh keys, and
>> any other persistent cryptographic (or even non-cryptographic) material,
>> this falls outside the scope of random seeding and into a general
>> machine cloning "sysprep"-like utility.
>=20
> systemd's seed utility will credit a seed file if the seed file was
> generated properly (e.g. after the RNG was initialized). For that they
> use the user.random-seed-creditable xattr, which is a reasonable way of
> deciding. If that attribute is present, it's credited; if it's not, it's
> not. Here's their source:
>=20
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* If we got this random seed data from getra=
ndom() the data is suitable for crediting
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* entropy later on. Let's keep that in =
mind by setting an extended attribute. on the file */
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (getrandom_worked)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (fsetxattr(see=
d_fd, "user.random-seed-creditable", "1", 1, 0) < 0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 log_full_errno(ERRNO_IS_NOT_SUPPORTED(errno) ? LOG_DEBUG : LOG_W=
ARNING, errno,
> =C2=A0  =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Failed to ma=
rk seed file as creditable, ignoring: %m");
>=20
> Since my seedrng.c is designed for more minimal systems (running
> buildroot or openrc or whatever), which might not have xattrs available,
> it distinguishes just based on the filename:
>=20
> 	if (new_seed_creditable && rename(NON_CREDITABLE_SEED, CREDITABLE_SEED) =
< 0) {
> 		fprintf(stderr, "ERROR: Unable to make new seed creditable: %s\n", stre=
rror(errno));
> 		program_ret |=3D 1 << 6;
> 	}
>=20
> It's no surprise that these are very similar; I've read systemd's
> seeding logic and contributed a fix to it.
>=20
> By the way, if you think something is different or wrong or whatever in
> seedrng.c, please feel free to send me a patch for it. It already
> received its first contribution this morning (from the buildroot
> maintainer). Hopefully the code will reach a good settling point soon,
> and then various projects that want it can just copy and paste it
> verbatim into their environment, and tweak idiomatic things as needed.
>=20
> Jason
>=20

Right, but I'm saying that even if the seed file is good when you wrote=20
it, it becomes bad if you copy it to multiple machines (e.g. by VM=20
cloning). For various reasons, I think this is outside the scope of the=20
random seed services to handle, but I think it's good to keep in mind.

Cheers,
Alex.