[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiHNtmCAWGWmUn7LYnwGWdNvDavhzBdNdeeTnP4Wkk3gg@mail.gmail.com>
Date: Mon, 16 Sep 2019 10:07:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: Lennart Poettering <mzxreary@...inter.de>,
"Alexander E. Patrakov" <patrakov@...il.com>,
"Ahmed S. Darwish" <darwish.07@...il.com>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
William Jon McCann <mccann@....edu>,
zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8
On Mon, Sep 16, 2019 at 10:00 AM Theodore Y. Ts'o <tytso@....edu> wrote:
>
> How /dev/random blocks is very different from how getrandom(2) blocks.
> Getrandom(2) blocks until the CRNG, and then it never blocks again.
Yes and no.
getrandom() very much blocks exactly like /dev/random, when you give
it the GRND_RANDOM flag.
Which is completely broken, and was already known to be broken. So
that flag is just plain stupid.
And getrandom() does *not* block like /dev/urandom does (ie not at
all), which was actually useful, and very widely used.
So you really have the worst of both worlds.
Yes, getrandom(0) does what /dev/random _should_ have done, and what
getrandom(GRND_RANDOM) should be but isn't.
But by making the choice it did, we now have three useless flag
combinations, and we lack one people _want_ and need.
And this design mistake very much caused the particular bug we are now hitting.
Linus
Powered by blists - more mailing lists