On Tue, Sep 17, 2019 at 10:42 AM Lennart Poettering
<mzxreary@xxxxxxxxxxx> wrote:
>
> So I think people nowadays prefer getrandom() over /dev/urandom
> primarily because of the noisy logging the kernel does when you use
> the latter on a non-initialized pool. If that'd be dropped then I am
> pretty sure that the porting from /dev/urandom to getrandom() you see
> in various projects (such as gdm/x11) would probably not take place.
Sad. So people were actually are perfectly happy with urandom, but you
don't want the warning, so you use getrandom() and as a result your
boot blocks.
What a sad sad reason for a bug.
Btw, having a "I really don't care deeply about some long-term secure
key" flag would soilve that problem too. We'd happily and silently
give you data.
The only reason we _do_ that silly printout for /dev/urandom is
exactly because /dev/random wasn't useful even for the people who
_really_ wanted secure randomness, so they started using /dev/urandom
despite the fact that it didn't necessarily have any entropy at all.
So this all actually fundamentally goes back to the absolutely horrid
and entirely wrong semantics of /dev/random that made it entirely
useless for the only thing it was actually designed for.
This is also an example of how hard-line "security" people that don't
see the shades of gray in between black and white are very much part
of the problem. If you have some unreasonable hard requirements,
you're going to do the wrong thing in the end.
At some point even security people need to realize that reality isn't
black-and-white. It's not also keeping us from making any sane
progress, I feel, because of that bogus "entropy is sacred", despite
the fact that our entropy calculations are actually just random
made-up stuff (but "hey, reasonable") to begin with and aren't really
black-and-white themselves.
> In fact, speaking for systemd: the noisy logging in the kernel is the
> primary (actually: only) reason that we prefer using RDRAND (if
> available) over /dev/urandom if we need "medium quality" random
> numbers, for example to seed hash tables and such. If the log message
> wasn't there we wouldn't be tempted to bother with RDRAND and would
> just use /dev/urandom like we used to for that.
That's also very sad. If we have rdrand, we'll actually mix it into
/dev/urandom regardless, so it's again just the whole "people started
using urandom for keys because random was broken" that is the cause of
this all.
I really really detest the whole inflexible "security" mindset.
> We can make boot hang in "sane", discoverable way.
That is certainly a huge advantage, yes. Right now I suspect that what
has happened is that this has probably been going on as some low-level
background noise for a while, and people either figured it out and
switched away from gdm (example: Christoph), or more likely some
unexplained boot problems that people just didn't chase down. So it
took basically a random happenstance to make this a kernel issue.
But "easily discoverable" would be good.
> The reason why I think this should also be logged by the kernel since
> people use netconsole and pstore and whatnot and they should see this
> there. If systemd with its infrastructure brings this to screen via
> plymouth then this wouldn't help people who debug much more low-level.
Well, I certainly agree with a kernel message (including a big
WARN_ON_ONCE), but you also point out that the last time we added
helpful messages to let people know, it had some seriously unintended
consequences ;)
Linus
