From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by sourceware.org (Postfix) with ESMTPS id 4A9063858D32 for ; Tue, 26 Jul 2022 11:20:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4A9063858D32 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 dfw.source.kernel.org (Postfix) with ESMTPS id E83AC60A6B; Tue, 26 Jul 2022 11:20:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9839C341C0; Tue, 26 Jul 2022 11:20:37 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 84e37221 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 26 Jul 2022 11:20:35 +0000 (UTC) Date: Tue, 26 Jul 2022 13:20:33 +0200 From: "Jason A. Donenfeld" To: Florian Weimer Cc: libc-alpha@sourceware.org, Adhemerval Zanella Netto , Cristian =?utf-8?Q?Rodr=C3=ADguez?= , Paul Eggert , linux-crypto@vger.kernel.org Subject: Re: [PATCH v2] arc4random: simplify design for better safety Message-ID: References: <20220725225728.824128-1-Jason@zx2c4.com> <20220725232810.843433-1-Jason@zx2c4.com> <87k080i4fo.fsf@oldenburg.str.redhat.com> <877d40i0v7.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <877d40i0v7.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2022 11:20:40 -0000 Hey Florian, On Tue, Jul 26, 2022 at 01:12:28PM +0200, Florian Weimer wrote: > >> What happens if /dev/random is actually /dev/urandom? Will the poll > >> call fail? > > > > Yes. I'm unsure if you're asking this because it'd be a nice > > simplification to only have to open one fd, or because you're worried > > about confusion. I don't think the confusion problem is one we should > > take too seriously, but if you're concerned, we can always fstat and > > check the maj/min. Seems a bit much, though. > > Turning /dev/random into /dev/urandom (e.g. with a symbolic link) used > to be the only way to get some applications working because they tried > to read from /dev/random at a higher rate than the system was estimating > entropy coming in. We may have to do something differently here if the > failing poll causes too much breakage. The "backup plan" would be to sleep-loop-read /proc/sys/kernel/random/entropy_avail until it passes a certain threshold one time. This might also work on even older kernels than the poll() trick. But that's pretty darn ugly, so it's not obvious to me where the cut-off in frustration is, when we throw our hands up and decide the ugliness is worth it compared to whatever problems we happen to be facing at the time with the poll() technique. But at least there is an alternative, should we need it. Jason