linux-kernel - Re: [PATCH] random: reseed in RNDRESEEDCRNG for the !crng

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YdMsMZU/PL7o2j5f@mit.edu>
Date:   Mon, 3 Jan 2022 12:02:41 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org, Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH] random: reseed in RNDRESEEDCRNG for the !crng_ready()
 case

On Mon, Jan 03, 2022 at 05:00:02PM +0100, Jason A. Donenfeld wrote:
> Userspace often wants to seed the RNG from disk, without knowing how
> much entropy is really in that file. In that case, userspace says
> there's no entropy, so none is credited. If this happens in the
> crng_init==1 state -- common at early boot time when such seed files are
> used -- then that seed file will be written into the pool, but it won't
> actually help the quality of /dev/urandom reads. Instead, it'll sit
> around until something does credit sufficient amounts of entropy, at
> which point, the RNG is seeded and initialized.
> 
> Rather than let those seed file bits sit around unused until "sometime
> later", userspaces that call RNDRESEEDCRNG can expect, with this commit,
> for those seed bits to be put to use *somehow*. This is accomplished by
> extracting from the input pool on RNDRESEEDCRNG, xoring 32 bytes into
> the current crng state.

I think this is fine, but the RNDRESEEDRNG ioctl is rarely used by
userspace.  From a Google search I see that jitterentropy uses it, but
in most setups it won't be called.

So something we could do to improve things is to add some code to
random_write() so that in the case where crng_init is 1, we take half
of the bytes or CHACHA_KEY_SIZE bytes, whichever is less, and pass
those bytes to crng_fast_load().  (We'll have to copy it to a bounce
buffer since the passed in pointer is __user, and memzero_explicit it
after calling crng_fast_load.)

This will divert some part of the seed file to partially initialize
the CRNG.  It won't fully initialize the CRNG, but that's fine, since
it's possible that the seed file has been compromised --- or is a
fixed value if the seed file is from coming a VM image file.  So
having at least half of the entropy used to initialize CRNG up to
crng_init=1 is coming from interrupt timing seems like a good thing.

					- Ted