Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1506380 > unrolled thread

why getrandom blocking does not work with /dev/urandom

Back to article view | Back to linux.kernel

Contents

  why getrandom blocking does not work with /dev/urandom Stephan Mueller <smueller@chronox.de> - 2016-10-22 05:50 +0200
    Re: why getrandom blocking does not work with /dev/urandom Theodore Ts'o <tytso@mit.edu> - 2016-10-22 07:20 +0200
      Re: why getrandom blocking does not work with /dev/urandom Stephan Mueller <smueller@chronox.de> - 2016-10-23 16:20 +0200

#1506380 — why getrandom blocking does not work with /dev/urandom

Hi Ted,

as mentioned, I looked a bit deeper into the issue of adding the blocking 
behavior of getrandom to /dev/urandom.

As you and I already identified, moving that blocking behavior to /dev/urandom 
simply does not work. The system does not boot.

The reason to this issue is actually quite simple. The init process of systemd 
reads /dev/urandom for whatever purpose. Now, when /dev/urandom blocks during 
boot, systemd will be blocked too. That means that user space (either in the 
initramfs or with the regular root partition) is set up.

When there is no user space initialized, there are no devices set up. The 
network card is not initialized, the block devices are not mounted, other 
devices are not initialized. That means that neither interrupts nor block 
device events are registered.

The only device that does not need setup and that will generate events is a 
keyboard / mouse whose drivers are statically compiled (or other devices that 
trigger interrupts without requiring any user space setup procedure). Thus, if 
you use HID long enough, the kernel will eventually receive sufficient entropy 
from these events, release systemd and user space starts.

However, just by itself, user space will almost never start with a blocking 
behavior of /dev/urandom.

Ciao
Stephan

[toc] | [next] | [standalone]

#1506383

On Sat, Oct 22, 2016 at 05:43:36AM +0200, Stephan Mueller wrote:
> Hi Ted,
> 
> as mentioned, I looked a bit deeper into the issue of adding the blocking 
> behavior of getrandom to /dev/urandom.
> 
> As you and I already identified, moving that blocking behavior to /dev/urandom 
> simply does not work. The system does not boot.
> 
> The reason to this issue is actually quite simple. The init process of systemd 
> reads /dev/urandom for whatever purpose. Now, when /dev/urandom blocks during 
> boot, systemd will be blocked too. That means that user space (either in the 
> initramfs or with the regular root partition) is set up.

I think you mean "is blocked from being set up".

> When there is no user space initialized, there are no devices set up. The 
> network card is not initialized, the block devices are not mounted, other 
> devices are not initialized. That means that neither interrupts nor block 
> device events are registered.

Well, those devices which are have already been initialized before
systemd starts will be fine.  Personally I believe in using built-in
drivers instead of depending on kernel modules for everything, but for
distribution kernels, yes, that's true.

In any case, yes, you're not telling me anything I didn't know.  What
I didn't know and still don't know is *why* systemd is tryinig to read
from /dev/urandom.  e.g., is it trying to initialize cryptographic
keys, the better to allow the Russians or the Chinese to set up
botnets which can take over IOT devices and paralyze root nameservers?
Or is it reading /dev/urandom for purely stupid, pointless,
non-cryptographic reasons?

I'm not sure which is worse, actually....

						- Ted

[toc] | [prev] | [next] | [standalone]

#1506708

Am Samstag, 22. Oktober 2016, 01:10:26 CEST schrieb Theodore Ts'o:

Hi Theodore,

> In any case, yes, you're not telling me anything I didn't know.  What
> I didn't know and still don't know is *why* systemd is tryinig to read
> from /dev/urandom.  e.g., is it trying to initialize cryptographic
> keys, the better to allow the Russians or the Chinese to set up
> botnets which can take over IOT devices and paralyze root nameservers?
> Or is it reading /dev/urandom for purely stupid, pointless,
> non-cryptographic reasons?

I thought that this was already clear given the following comment in systemd 
(function dev_urandom which is invoked by other code parts within systemd):

        /* Gathers some randomness from the kernel. This call will
         * never block, and will always return some data from the
         * kernel, regardless if the random pool is fully initialized
         * or not. It thus makes no guarantee for the quality of the
         * returned entropy, but is good enough for our usual usecases
         * of seeding the hash functions for hashtable */

So, using /dev/urandom is for noncryptographic purposes. The interesting thing 
however is that the code has the getrandom syscall invocation which seems that 
it is not used.


Aside from seeding hash tables, the mentioned function is also used for the 
following purposes:

- seed to generate a UUID (sd_id128_randomize) -- even in the code, comments 
are present that mention that the UUID generation code has been taken from the 
kernel. Thus, to circumvent the opening of /dev/urandom in this case, /proc/
sys/kernel/random/uuid should be used

- some namespace setup code pulls data from /dev/urandom (uid_shift_pick) -- 
again I cannot see a cryptographic use case

- random numbers are used for some DNS related use cases 
(dns_scope_make_conflict_packet, dns_scope_notify_conflict, pick_new_id) -- 
again, no crypto use case

- the creation of some random host name uses /dev/urandom 
(manager_next_hostname)

- get a random MAC address uses /dev/urandom (get_mac)


All in all, I see no cryptographic use case for any of the calls to /dev/
urandom. So, I would think that systemd can be improved to not pull /dev/
urandom at least during boot time.

Yet, even when systemd is updated, I fear that we cannot update the kernel to 
block /dev/urandom as it would break older systemd setups.

Ciao
Stephan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web