Excerpts from Jason A. Donenfeld's message of March 23, 2022 11:18 pm:
> Hi all,
>
> [...]
>
> 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.
>
> 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 there.
>
> 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.
>
> Jason
>
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.
Cheers,
Alex.
Hi Alex,
On Thu, Mar 24, 2022 at 10:29 AM Alex Xu (Hello71) <[email protected]> wrote:
>
> Excerpts from Jason A. Donenfeld's message of March 23, 2022 11:18 pm:
> > Hi all,
> >
> > [...]
> >
> > 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.
> >
> > 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 there.
> >
> > 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.
> >
> > Jason
> >
>
> 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.
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:
/* If we got this random seed data from getrandom() the data is suitable for crediting
* entropy later on. Let's keep that in mind by setting an extended attribute. on the file */
if (getrandom_worked)
if (fsetxattr(seed_fd, "user.random-seed-creditable", "1", 1, 0) < 0)
log_full_errno(ERRNO_IS_NOT_SUPPORTED(errno) ? LOG_DEBUG : LOG_WARNING, errno,
"Failed to mark seed file as creditable, ignoring: %m");
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:
if (new_seed_creditable && rename(NON_CREDITABLE_SEED, CREDITABLE_SEED) < 0) {
fprintf(stderr, "ERROR: Unable to make new seed creditable: %s\n", strerror(errno));
program_ret |= 1 << 6;
}
It's no surprise that these are very similar; I've read systemd's
seeding logic and contributed a fix to it.
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.
Jason