From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6918 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 17:02:29 -0500 Message-ID: <20150128220229.GL4574@brightrain.aerifal.cx> References: <20150128154108.GH32318@port70.net> <20150128160352.GI32318@port70.net> <20150128162104.GJ4574@brightrain.aerifal.cx> <20150128191746.GK4574@brightrain.aerifal.cx> <3AC86046-063E-4437-9BF6-F411E7C8C6E9@gmail.com> 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 1422482565 1048 80.91.229.3 (28 Jan 2015 22:02:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 22:02:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6931-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 28 23:02:44 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 1YGahA-00069v-4R for gllmg-musl@m.gmane.org; Wed, 28 Jan 2015 23:02:44 +0100 Original-Received: (qmail 25976 invoked by uid 550); 28 Jan 2015 22:02:42 -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 25968 invoked from network); 28 Jan 2015 22:02:42 -0000 Content-Disposition: inline In-Reply-To: <3AC86046-063E-4437-9BF6-F411E7C8C6E9@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6918 Archived-At: On Wed, Jan 28, 2015 at 02:20:16PM -0600, Brent Cook wrote: > >> 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. > > Yes, that is a better description. Failing when receiving EINTR to avoid > an infinite loop is an interesting idea, but getentropy is documented > as only failing under a very narrow range of conditions: > > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 OK. The conditions for EIO are left sort of open-ended, but it seems the intent is that this function not fail with valid inputs. I think we should follow that intent if we provide the function, which means both ignoring EINTR and providing a fallback for ENOSYS. > > 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? > > You can see a variety of fallbacks there, and AT_RANDOM is included, > though that is not available on every kernel either. If you're going to > implement such a CSPRNG, the C library seems the place to do it though. At this point I think what's clear is that we should provide the syscall wrapper for getrandom. What to do with getentropy is less clear, and it looks to be a fair bit of work/code-size to get a robust getentropy suitable for application usage. I don't want to copy the idiotic stuff libressl is doing, but I think the following fallback sequence would be reasonable: 1. Try SYS_getrandom. Fails on even mildly-old kernels. 2. Try opening /dev/urandom. Fails under fd pressure or broken chroots/containers/lsms/etc. 3. Try AT_RANDOM+CSPRNG. Fails on ancient (what version?) kernels. I don't know what to after that, but I suspect/hope that any kernel too old to have AT_RANDOM is full of so many gaping security holes that lack of working entropy source is the least of anyone's problems. As for CSPRNG, what would be acceptably small and secure? CTR mode using a block cipher and AT_RANDOM as the key? Could we reuse crypto code out of crypt/*.c? Or just call crypt_r directly? Rich