linux-kernel - Re: [PATCH v2 05/10] random: group crng functions

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: <CAHmME9qLOWKHeA13bfzq9OKRi_M0ANqz4CXZHrLzAjesVGTOdg@mail.gmail.com>
Date:   Sun, 13 Feb 2022 14:14:32 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Dominik Brodowski <linux@...inikbrodowski.net>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        "Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH v2 05/10] random: group crng functions

Hi Dominik,

On Sun, Feb 13, 2022 at 7:57 AM Dominik Brodowski
<linux@...inikbrodowski.net> wrote:
> No, it's for crng_init == 0 only.

Right! Nice catch, thanks.

> > + * Batched entropy returns random integers. The quality of the random
> > + * number is good as /dev/urandom. In order to ensure that the randomness
>
> /dev/random

/dev/urandom is the right analogy, actually, since batched entropy won't wait.

> > +size_t __must_check get_random_bytes_arch(void *buf, size_t nbytes)
>
> Sidenote: We should get rid of the sole caller of that function, and then of
> this function. AFAICS, using get_random_bytes() (once rand_initialize() has
> been called) should never be less secure than get_random_bytes_arch() IFF
> arch_get_random_long() exists -- which is what the sole caller seems to be
> interested in.

I agree entirely that we should get rid of this. I think the issue is
vsprintf needs a stable key for siphash that never changes once
initialized, and the earlier they can get something good enough, the
better. If they can't get something good, vsprintf needs to know so it
can defer that to later. So I'm not yet sure the right way to solve
it, but I agree we should find some way to ditch this function.

Jason