Discussion:
[tytso@mit.edu: Re: Linux messages full of `random: get_random_u32 called from`]
(too old to reply)
Vito Caputo
2018-05-02 01:08:09 UTC
Permalink
Raw Message
Hello systemd-devel,

There's an ongoing discussion @ lkml about early boot random number
entropy, or the lack of it, and how it may hang systemd-using instances
from booting indefinitely.

Ted Ts'o is questioning the validity of journal-authenticate's early
random number usage, maybe some of you care to comment.

Please find the forwarded message below.

Regards,
Vito Caputo


----- Forwarded message from "Theodore Y. Ts'o" <***@mit.edu> -----

Date: Tue, 1 May 2018 20:56:04 -0400
From: "Theodore Y. Ts'o" <***@mit.edu>
To: Sultan Alsawaf <***@gmail.com>
Cc: Justin Forbes <***@linuxtx.org>, Jeremy Cline <***@jcline.org>, Pavel
Machek <***@ucw.cz>, LKML <linux-***@vger.kernel.org>, Jann Horn
<***@google.com>
Subject: Re: Linux messages full of `random: get_random_u32 called from`
User-Agent: Mutt/1.9.5 (2018-04-13)
I've attached what I think is a reasonable stopgap solution until this is
actually fixed. If you're willing to revert the CVE-2018-1108 patches
completely, then I don't think you'll mind using this patch in the meantime.
I would put it slightly differently; reverting the CVE-2018-1108
patches is less dangerous than what you are proposing in your attached
patch.

Again, I think the right answer is to fix userspace to not require
cryptographic grade entropy during early system startup, and for
people to *think* about what they are doing. I've looked at the
systemd's use of hmac in journal-authenticate, and as near as I can
tell, there isn't any kind of explanation about why it was necessary,
or what threat it was trying to protect against.

- Ted

----- End forwarded message -----
Lennart Poettering
2018-05-02 09:25:40 UTC
Permalink
Raw Message
Post by Vito Caputo
Hello systemd-devel,
entropy, or the lack of it, and how it may hang systemd-using instances
from booting indefinitely.
Ted Ts'o is questioning the validity of journal-authenticate's early
random number usage, maybe some of you care to comment.
There appears to be some confusion there...

journal-authenticate.c only has an effect if forward secure sealing is
turned on, which it isn't by default, people have to explicitly
generate a keypair first. And it's the generation of that keypair that
requires proper (cryptographic) entropy — but this is generally not
done on boot. Hence, yes there's some code that requires proper
cryptographic entropy, and for a valid reason, but that code is
neither run on boot, nor run unless explicitly enabled.

Or maybe this confusion is just another iteration of the stuff
dicussed here? https://github.com/systemd/systemd/issues/4167

(Every single time I posted something on kernel mailing lists in the
past years I got excessively nasty mails back from kernel community
members, about that I should go and die and suchlike, and hence I am
generally refraining to post on kernel mailing lists, which is why I
am replying here, and not there... I know that sucks, but they really
need to fix their community first)

Lennart
Cristian Rodríguez
2018-05-02 15:23:33 UTC
Permalink
Raw Message
Post by Lennart Poettering
Or maybe this confusion is just another iteration of the stuff
dicussed here? https://github.com/systemd/systemd/issues/4167
On modern x86 hardware we could fallback to rdrand but only when
getrandom returns EAGAIN.

For other non-cryptographic uses maybe implementing xoroshiro128+ or
Mersenne Twister would suffice, until libc gets a sane random interface
if ever.
Zbigniew Jędrzejewski-Szmek
2018-05-07 13:02:51 UTC
Permalink
Raw Message
Post by Cristian Rodríguez
Post by Lennart Poettering
Or maybe this confusion is just another iteration of the stuff
dicussed here? https://github.com/systemd/systemd/issues/4167
That bug was closed after some improvements, but based on the comments
there we can conclude that systemd *does* consume a lot of random bytes
from /dev/urandom and even though we are using the kernel APIs as documented,
it would be nice if were didn't use read all this random data, because
that impacts other processes that need random data.

But to change how much random bytes we use, we'd need to refactor
the code, because right now by the time we get to the part that
actually reads the bytes, we're far from the caller who knows if we
need really proper random bytes or we would be fine with some fluff.

I wasn't aware that this is still a problem. If it is, it'd probably
be worth looking into.
Post by Cristian Rodríguez
On modern x86 hardware we could fallback to rdrand but only when
getrandom returns EAGAIN.
For other non-cryptographic uses maybe implementing xoroshiro128+ or
Mersenne Twister would suffice, until libc gets a sane random
interface if ever.
Yeah, that's something to look into to. But that'd still probably
need the refactoring to pass down more information about how those
numbers will be used.

Zbyszek

Loading...