From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6915 Path: news.gmane.org!not-for-mail From: Brent Cook Newsgroups: gmane.linux.lib.musl.general Subject: Re: getrandom syscall Date: Wed, 28 Jan 2015 14:20:16 -0600 Message-ID: <3AC86046-063E-4437-9BF6-F411E7C8C6E9@gmail.com> References: <20150128145410.GH4574@brightrain.aerifal.cx> <20150128154108.GH32318@port70.net> <20150128160352.GI32318@port70.net> <20150128162104.GJ4574@brightrain.aerifal.cx> <20150128191746.GK4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422476365 24500 80.91.229.3 (28 Jan 2015 20:19:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 20:19:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6928-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 28 21:19:25 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 1YGZ5A-00026i-Iy for gllmg-musl@m.gmane.org; Wed, 28 Jan 2015 21:19:24 +0100 Original-Received: (qmail 24407 invoked by uid 550); 28 Jan 2015 20:19:22 -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 24396 invoked from network); 28 Jan 2015 20:19:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=OKNpjfZYhnOu6OmVUTYV9Cizu/et1hm6+Q0yCSl4yD4=; b=hFXl4vUaOrSkWgXgCVYKepoO055rIjM4ituA976KvxbM1Nvg5SHF/BWCcp6AM63khI tGTkQM26aJfr6TuVu3mVz026czmFa5J2wtyzDsCG8rLoW6AnQJbmFVz3ih3oAcSekMZK pRIzRibZpdL8djqLkFXI3eP9Zf5Vj/WCI/59qBznwQuPJoQWGWnIlQu94JlsruEHcxX3 32CLomgcfUlZSRk3FKndZ/PUMGEV+u2GlGQgYtIhtQA8ZAKECnpp0XsEYkd68HqYbHsc 6ev+aFIY2Gw7MvCzp2fP4YBHt50iF4AuVX90WTLqp1OHSeNc2j09g307gU4YOtQ43qYg tbqQ== X-Received: by 10.182.91.6 with SMTP id ca6mr3265776obb.17.1422476350596; Wed, 28 Jan 2015 12:19:10 -0800 (PST) In-Reply-To: <20150128191746.GK4574@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.2070.6) Xref: news.gmane.org gmane.linux.lib.musl.general:6915 Archived-At: > On Jan 28, 2015, at 1:17 PM, Rich Felker wrote: >=20 > 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: >>=20 >> = https://github.com/libressl-portable/openbsd/blob/master/src/lib/libcrypto= /crypto/getentropy_linux.c#L194 >=20 > This version is failing to set errno when rejecting len>256, which > looks bad. Right, it's not actually a problem in context of the whole file. This is just the first of several fallbacks called by getentropy. I think that was there originally just to remind what the limit is before it changes blocking behavior. In this context, it can also fail with ENOSYS too, so this on function is not a standalone gententropy emulation. >> It tries to avoid a couple of possible issues. FIrst, while <=3D 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. >=20 > 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 >> Then, to avoid modifying errno even though there was an actual >> success, the wrapper restores the previous errno value when it >> succeeds. >=20 > Avoiding modification of errno when the call succeeds is not necessary > or desirable. Callers should not be assuming errno is untouched after > success. I think the difference here was that this is attempting to emulate a syscall, rather than a library function, so its trying to only set errno on failure. This was suggested to me by Theo de Raadt. But, you're right, callers shouldn't expect either anyway. >> 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. >=20 > Indeed, that masks the issue I mentioned above. Right, this is just one of several entropy methods that it calls in order to perform the emulation. The outer getentropy() function is the one that matters. > 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? >=20 >> 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. >=20 > 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. - Brent