From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id C28863858D32 for ; Tue, 26 Jul 2022 11:35:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C28863858D32 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-10d867a8358so18203997fac.10 for ; Tue, 26 Jul 2022 04:35:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=JR7hze4sDCYLNq+WCqxMqOHF13T7qF4AuVi9kdIgtxc=; b=5bCisdko2rVdr7boS/H74m1iqhQZWQ3IlthQf/jjMKTfO7LDDzpYfMqxDQr+OzM3K0 LissL5afXN6hqsYgJs94g6N2wilKLJcNMypCVDpTdrs+ZmSOoV+G9DdGMWSvykgXZA2Y uuTjEhduKPy+oTgh60ybju0YA8XhmJdmedXoqGbMwRBihBEu7DHKjkBcGZavtkQvIgcN zvr+tvIcekC+s32S1v5QAJRPn0OF6lmmCDNs259TPyti6oIpQWC3KlBpl3ImihZ91pY3 a80Nw++nZ0lVc85E9cIeioFjr/5DWps2lEqQsQ01hqJDjpdM20j8LbSQ16wj7l+CyRYp Jy3Q== X-Gm-Message-State: AJIora+kRHipt1uHvNbCdT1zi0GI2EJ/8faxwxwy8TQRDl+7X1e/CUrq IvfInsYjz40qZ5L+uQdAPV1c3g== X-Google-Smtp-Source: AGRyM1uPotPz6VrmzVkL/ggmMf0MWeBx87+MwjXCxtmOny3D4VuqFwFlu+aUZKpwPpMlnCIl4rMr5Q== X-Received: by 2002:a05:6870:819e:b0:10e:d42:c25 with SMTP id k30-20020a056870819e00b0010e0d420c25mr5262633oae.267.1658835324186; Tue, 26 Jul 2022 04:35:24 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:8ded:8925:49f1:c550:ee7d? ([2804:431:c7cb:8ded:8925:49f1:c550:ee7d]) by smtp.gmail.com with ESMTPSA id m22-20020a4ad516000000b0043575a93b1fsm5826676oos.30.2022.07.26.04.35.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Jul 2022 04:35:23 -0700 (PDT) Message-ID: <0319b66f-b3b5-3357-1fa9-c9e1d2448427@linaro.org> Date: Tue, 26 Jul 2022 08:35:21 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: [PATCH v2] arc4random: simplify design for better safety Content-Language: en-US To: "Jason A. Donenfeld" , Florian Weimer Cc: libc-alpha@sourceware.org, =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , Paul Eggert , linux-crypto@vger.kernel.org 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> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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:35:26 -0000 On 26/07/22 08:20, Jason A. Donenfeld wrote: > 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. I think the poll trick is way better, although I also think it is very Linux specific. Should we move it to Linux sysdeps? The /proc/sys/kernel/random/entropy_avail would require to open another file descriptor, which I think we avoid for arc4random if possible.