All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>
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>
Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast init
Date: Thu, 24 Mar 2022 15:03:50 -0400	[thread overview]
Message-ID: <1648148400.ytc07g7pbi.none@localhost> (raw)
In-Reply-To: <YjyoaEZLb+GzxJFT@zx2c4.com>

Excerpts from Jason A. Donenfeld's message of March 24, 2022 1:20 pm:
> Hi Alex,
> 
> On Thu, Mar 24, 2022 at 10:29 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>> 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
> 

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

Cheers,
Alex.

  reply	other threads:[~2022-03-24 19:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 19:14 [PATCH] random: allow writes to /dev/urandom to influence fast init Jason A. Donenfeld
2022-03-22 20:42 ` Linus Torvalds
2022-03-22 23:54   ` Jason A. Donenfeld
2022-03-23  2:15 ` David Laight
2022-03-23  2:50   ` Jason A. Donenfeld
2022-03-23  8:43     ` Rasmus Villemoes
2022-03-24 14:12       ` Jason A. Donenfeld
2022-03-23 11:45     ` David Laight
2022-03-23  3:35 ` Theodore Ts'o
2022-03-23  4:00   ` Jason A. Donenfeld
2022-03-23 12:31     ` Theodore Ts'o
2022-05-23 17:59     ` Pavel Machek
2022-03-23  4:30 ` Alex Xu (Hello71)
2022-03-23  4:47   ` Jason A. Donenfeld
2022-03-23 14:01     ` David Laight
2022-03-23 19:53       ` Jason A. Donenfeld
2022-03-24 18:01         ` Eric Biggers
2022-03-24  3:18     ` Jason A. Donenfeld
2022-03-24 16:28       ` Alex Xu (Hello71)
2022-03-24 17:20         ` Jason A. Donenfeld
2022-03-24 19:03           ` Alex Xu (Hello71) [this message]
2022-03-24 18:26       ` Eric Biggers
2022-03-24 18:31         ` Jason A. Donenfeld
2022-06-19 16:44       ` Pavel Machek
2022-03-24 19:53 ` Eric Biggers
2022-03-24 20:25   ` Jason A. Donenfeld
2022-06-19 16:56     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1648148400.ytc07g7pbi.none@localhost \
    --to=alex_y_xu@yahoo.ca \
    --cc=Jason@zx2c4.com \
    --cc=jannh@google.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=linux@roeck-us.net \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.