From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756405AbcJWOKB (ORCPT ); Sun, 23 Oct 2016 10:10:01 -0400 Received: from mail.eperm.de ([89.247.134.16]:46462 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755967AbcJWOKA (ORCPT ); Sun, 23 Oct 2016 10:10:00 -0400 From: Stephan Mueller To: "Theodore Ts'o" Cc: linux-kernel@vger.kernel.org Subject: Re: why getrandom blocking does not work with /dev/urandom Date: Sun, 23 Oct 2016 16:09:50 +0200 Message-ID: <3344810.FOR7goHsm1@positron.chronox.de> User-Agent: KMail/5.3.1 (Linux/4.7.9-200.fc24.x86_64; KDE/5.26.0; x86_64; ; ) In-Reply-To: <20161022051025.zlukolzr4ifil64r@thunk.org> References: <13074229.arz8HkBRPc@positron.chronox.de> <20161022051025.zlukolzr4ifil64r@thunk.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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