From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6913 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getrandom syscall Date: Wed, 28 Jan 2015 14:17:46 -0500 Message-ID: <20150128191746.GK4574@brightrain.aerifal.cx> References: <20150128145410.GH4574@brightrain.aerifal.cx> <20150128154108.GH32318@port70.net> <20150128160352.GI32318@port70.net> <20150128162104.GJ4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1422472681 25898 80.91.229.3 (28 Jan 2015 19:18:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 19:18:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6926-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 28 20:18:01 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YGY7k-0001Z2-LR for gllmg-musl@m.gmane.org; Wed, 28 Jan 2015 20:18:00 +0100 Original-Received: (qmail 30541 invoked by uid 550); 28 Jan 2015 19:17:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30533 invoked from network); 28 Jan 2015 19:17:58 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6913 Archived-At: On Wed, Jan 28, 2015 at 11:43:17AM -0600, Brent Cook wrote: > Here is the wrapper in LibreSSL for getrandom, to hopefully lend to > the discussion: > > https://github.com/libressl-portable/openbsd/blob/master/src/lib/libcrypto/crypto/getentropy_linux.c#L194 This version is failing to set errno when rejecting len>256, which looks bad. > It tries to avoid a couple of possible issues. FIrst, while <= 256 > byte getrandom should not interrupt, it appears that if the kernel > entropy pool has not been initialized yet, it would still return EINTR > if called early enough in the boot process. How likely this is in > practice, I don't know. You mean it would block and be subject to EINTR if a signal occurs? In this case I would think you'd probably _want_ the EINTR to cause it to fail. I can imagine an early-boot program using SIGALRM to prevent waiting too-long/forever for entropy that's not going to arrive. > Then, to avoid modifying errno even though there was an actual > success, the wrapper restores the previous errno value when it > succeeds. Avoiding modification of errno when the call succeeds is not necessary or desirable. Callers should not be assuming errno is untouched after success. > I just realized that the length check in getentropy_getrandom() is > redundant, since it is checked earlier in getentropy() as well, but > hopefully this is helpful. Indeed, that masks the issue I mentioned above. So, their version of getentropy is aiming to provide a meaningful result even on systems that don't have SYS_getrandom. Should we be doing the same? > If a getentropy() were added to musl libc, but in such a way that it > might fail on older kernels, that would cause some problems with > LibreSSL, and now OpenNTPD. They will both try to use getentropy() > with arc4random() if it is found in a system, and arc4random() will > treat a getentropy() failure as fatal. Yes, this sounds bad. So what fallbacks should we implement? Do we need a strong CSPRNG on top of AT_RANDOM? Rich