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 0985B3858C39 for ; Sat, 23 Jul 2022 22:59:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0985B3858C39 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 9D7E3609FE; Sat, 23 Jul 2022 22:59:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22A4DC341C0; Sat, 23 Jul 2022 22:59:42 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 89d74c6a (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sat, 23 Jul 2022 22:59:40 +0000 (UTC) Date: Sun, 24 Jul 2022 00:59:37 +0200 From: "Jason A. Donenfeld" To: Cristian =?utf-8?Q?Rodr=C3=ADguez?= Cc: libc-alpha@sourceware.org, Adhemerval Zanella Netto , Florian Weimer , Yann Droneaud , jann@thejh.net, Michael@phoronix.com, linux-crypto@vger.kernel.org Subject: Re: arc4random - are you sure we want these? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.8 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: Sat, 23 Jul 2022 22:59:45 -0000 Hi Cristian, On Sat, Jul 23, 2022 at 03:04:36PM -0400, Cristian Rodríguez wrote: > On linux just making this interface call "something" from the VDSO that > > - does not block. > - cannot ever fail or if it does indeed need to bail out it kills the > calling thread as last resort. > > (if neither of those can be provided, we are back to square one) > > Will be beyond awesome because it could be usable everywhere, > including the dynamic linker, malloc or whatever else > question is..is there any at least experimental patch with a hope of > beign accepted available ? Doesn't getrandom() already basically have this quality? If you call getrandom(0), it'll block until the RNG is initialized once (which now happens pretty reliably early on in boot). If you call getrandom(GRND_ INSECURE), it will skip that blocking. Both mechanisms are reliable and available on all current kernel.org stable kernels. Is there something about these you don't like and think need fixing? I'm open to suggestions on how to further improve that interface if it has a notable shortcoming. If somebody has a compelling performance case that's widespread and can't be fixed in the kernel alone, I wouldn't be adverse to vDSOing it. But such an undertaking would probably be contingent on doing this with the glibc developers, rather than trying to retroactively bandaid an addition that shipped broken with a documentation cop-out. Jason