Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5812042pxb; Mon, 14 Feb 2022 08:10:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJwx7pXgjd7E9vcCy3S5WK6Wu+xRZk55Ay+G1bJ4pKYMphFwmo1tgdNrTUlQcerZky9C1zTS X-Received: by 2002:a50:c041:: with SMTP id u1mr301480edd.105.1644855024014; Mon, 14 Feb 2022 08:10:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644855024; cv=none; d=google.com; s=arc-20160816; b=vMEh+Ev0J2DQjSD7Yd75f4CHKzTkm1BobH5QIYJvUOCfObyOQhNchbZsX6rldqapo4 gFTfW1skltVEvC1Pqnhm2prcTaw9KeMriljdvd2SM8XX1jSPX2JYC6Ai1Q3tLKz0RVFZ L/g5kAEnAleJmxkY/d3yXoV7013F8HJ9bV5YSunXUtvFf/eMf6NJvDieqv+g+ypuxHC2 q566G1XPhSA3X+N052m0B8W6XIluVDfBv/ZbwdHnUh92us5Lv32A39PVvv4Cet05dvHr op/y7lgaA3pATHMhV+JypRlGyU/+gePp2SDpQvDU1EEENEPzTUgkZ12U30r4IrGnBvZz iBsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gNy906fCfgtg3rrlPPwGuVAeoK9jD6AuJHW2V5mt6m4=; b=YovtEyMQLFMJCuEgdg9xBNRqQN5tnuMtf49N1Bke4nA8w6zKanopSebJdvj7WPYfhS MYYNLs382SwBAlJkF1AaB+3JK0DFnRDw0FY6ZJIrdfyMDaI3x+jDEKHiuOI2bquxjiSa JTlmYuABQZFCy2R215UzfIbHxKRCZtJoN8rSX/CL42wu6hWNnpyN1D7FWgkx+qr4sOtd wq91USCzzSmPgfpvtlHK+g60QPdxP005Kcnbm/WoGxaqb+xiroJPFXW/dN8/CnBs9x4X sGrlCBNlIdjc/LRDfBacH4O97BOBGGelZS6xUCBIkTGwphhNzYZl7L+kU4pcHphXTVMd QIIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=JYW49XlR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qx27si836367ejb.206.2022.02.14.08.09.56; Mon, 14 Feb 2022 08:10:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=JYW49XlR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355006AbiBNOP4 (ORCPT + 99 others); Mon, 14 Feb 2022 09:15:56 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:51796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355051AbiBNOPv (ORCPT ); Mon, 14 Feb 2022 09:15:51 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF5DFCF2; Mon, 14 Feb 2022 06:15:43 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AA18AB80FEA; Mon, 14 Feb 2022 14:15:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96287C340E9; Mon, 14 Feb 2022 14:15:39 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="JYW49XlR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1644848138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gNy906fCfgtg3rrlPPwGuVAeoK9jD6AuJHW2V5mt6m4=; b=JYW49XlRspfC2c1nAI7Rfr4oIINd+RuhXGm5Ttly1yB27rz1bFbcu6Ct+BN4DV13mAqwVF LL00LWvDILFvpHMGSA4EYXjEwmcKHXE3Wnw83XR5+D9JYLG27u54YwGQrtwl2xy+/xab4B TxuVSVkwFNxpCkhoN78MHWULosvWt9g= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id d91a5074 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 14 Feb 2022 14:15:37 +0000 (UTC) Date: Mon, 14 Feb 2022 15:13:18 +0100 From: "Jason A. Donenfeld" To: Lennart Poettering Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, Geert Uytterhoeven , linux-m68k@lists.linux-m68k.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, Dominik Brodowski , Eric Biggers , Ard Biesheuvel , Arnd Bergmann , Thomas Gleixner , Andy Lutomirski , Kees Cook , Linus Torvalds , Greg Kroah-Hartman , Theodore Ts'o Subject: Re: [PATCH RFC v0] random: block in /dev/urandom Message-ID: References: <20220211210757.612595-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lennart, On Mon, Feb 14, 2022 at 9:53 AM Lennart Poettering wrote: > So, systemd uses (potentially half-initialized) /dev/urandom for > seeding its hash tables. For that its kinda OK if the random values > have low entropy initially, as we'll automatically reseed when too > many hash collisions happen, and then use a newer (and thus hopefully > better) seed, again acquired through /dev/urandom. i.e. if the seeds > are initially not good enough to thwart hash collision attacks, once > the hash table are actually attacked we'll replace the seeds with > someting better. For that all we need is that the random pool > eventually gets better, that's all. > > So for that usecase /dev/urandom behaving the way it so far does is > kinda nice. Oh that's an interesting point. But that sounds to me like the problem with this patch is not that it makes /dev/urandom block (its primary purpose) but that it also removes GRND_INSECURE (a distraction). So perhaps an improved patch would be something like the below, which changes /dev/urandom for new kernels but doesn't remove GRND_INSECURE. Then your hash tables could continue to use GRND_INSECURE and all would be well. (And for kernels without getrandom(), they'd just fall back to /dev/urandom like normal which would have old semantics, so works.) Jason ---------8<-----------------8<------------------------------- diff --git a/drivers/char/mem.c b/drivers/char/mem.c index cc296f0823bd..9f586025dbe6 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -707,7 +707,7 @@ static const struct memdev { [5] = { "zero", 0666, &zero_fops, FMODE_NOWAIT }, [7] = { "full", 0666, &full_fops, 0 }, [8] = { "random", 0666, &random_fops, 0 }, - [9] = { "urandom", 0666, &urandom_fops, 0 }, + [9] = { "urandom", 0666, &random_fops, 0 }, #ifdef CONFIG_PRINTK [11] = { "kmsg", 0644, &kmsg_fops, 0 }, #endif diff --git a/drivers/char/random.c b/drivers/char/random.c index ce199af9bc56..ae4400c48b2f 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -89,8 +89,6 @@ static LIST_HEAD(random_ready_list); /* Control how we warn userspace. */ static struct ratelimit_state unseeded_warning = RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3); -static struct ratelimit_state urandom_warning = - RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3); static int ratelimit_disable __read_mostly; module_param_named(ratelimit_disable, ratelimit_disable, int, 0644); MODULE_PARM_DESC(ratelimit_disable, "Disable random ratelimit suppression"); @@ -336,11 +334,6 @@ static void crng_reseed(void) unseeded_warning.missed); unseeded_warning.missed = 0; } - if (urandom_warning.missed) { - pr_notice("%d urandom warning(s) missed due to ratelimiting\n", - urandom_warning.missed); - urandom_warning.missed = 0; - } } } @@ -993,10 +986,8 @@ int __init rand_initialize(void) pr_notice("crng init done (trusting CPU's manufacturer)\n"); } - if (ratelimit_disable) { - urandom_warning.interval = 0; + if (ratelimit_disable) unseeded_warning.interval = 0; - } return 0; } @@ -1387,20 +1378,17 @@ static void try_to_generate_entropy(void) * getrandom(2) is the primary modern interface into the RNG and should * be used in preference to anything else. * - * Reading from /dev/random has the same functionality as calling - * getrandom(2) with flags=0. In earlier versions, however, it had - * vastly different semantics and should therefore be avoided, to - * prevent backwards compatibility issues. - * - * Reading from /dev/urandom has the same functionality as calling - * getrandom(2) with flags=GRND_INSECURE. Because it does not block - * waiting for the RNG to be ready, it should not be used. + * Reading from /dev/random and /dev/urandom both the same effect as + * calling getrandom(2) with flags=0. In earlier versions, however, + * they each had vastly different semantics and should therefore be + * avoided to prevent backwards compatibility issues. * * Writing to either /dev/random or /dev/urandom adds entropy to * the input pool but does not credit it. * - * Polling on /dev/random indicates when the RNG is initialized, on - * the read side, and when it wants new entropy, on the write side. + * Polling on /dev/random or /dev/urandom indicates when the RNG + * is initialized, on the read side, and when it wants new entropy, + * on the write side. * * Both /dev/random and /dev/urandom have the same set of ioctls for * adding entropy, getting the entropy count, zeroing the count, and @@ -1485,21 +1473,6 @@ static ssize_t random_write(struct file *file, const char __user *buffer, return (ssize_t)count; } -static ssize_t urandom_read(struct file *file, char __user *buf, size_t nbytes, - loff_t *ppos) -{ - static int maxwarn = 10; - - if (!crng_ready() && maxwarn > 0) { - maxwarn--; - if (__ratelimit(&urandom_warning)) - pr_notice("%s: uninitialized urandom read (%zd bytes read)\n", - current->comm, nbytes); - } - - return get_random_bytes_user(buf, nbytes); -} - static ssize_t random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos) { @@ -1586,15 +1559,6 @@ const struct file_operations random_fops = { .llseek = noop_llseek, }; -const struct file_operations urandom_fops = { - .read = urandom_read, - .write = random_write, - .unlocked_ioctl = random_ioctl, - .compat_ioctl = compat_ptr_ioctl, - .fasync = random_fasync, - .llseek = noop_llseek, -}; - /******************************************************************** *