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] [day] [month] [year] [list]

Message-ID: <CAHmME9qJtA2BGjXUn2WQVFUNr3OdAo__BS-nVst5mhYhfsA8GA@mail.gmail.com>
Date:   Mon, 3 Jan 2022 18:26:39 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     LKML <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 3, 2022 at 6:02 PM Theodore Ts'o <tytso@....edu> wrote:
>
> 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.

Yea, doing things in RNDADDENTROPY or random_write is a possibility,
and then userspace doesn't need to adopt new strange things. In
looking at this, though, and combined with the attitude of the
crng_init_cnt=0 commit from last hour, I'm beginning to think that
trying to cater toward crng_init<2 usage is an exercise in madness. We
provide getrandom(..., 0)'s blocking mode for users who want things to
be real. If you're not doing this (or can't due to old kernels), you
should probably Know What You're Doing and adjust accordingly. To that
end, I'm not convinced this patch or similar ideas of making
crng_init=1 mode more useful really has much of a future.

However, it does seem like userspaces who know what they're doing
*can* take necessary countermeasures for the seeding use case that
Jann originally identified as being potentially problematic. To that
end, I submitted a PR to systemd:
https://github.com/systemd/systemd/pull/21986 . We'll see what they
think.

Jason