From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6896 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Daniel_Cegie=C5=82ka?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: getrandom syscall Date: Wed, 28 Jan 2015 16:41:28 +0100 Message-ID: References: <20150128145410.GH4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1422459724 22437 80.91.229.3 (28 Jan 2015 15:42:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 15:42:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6909-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 28 16:42:03 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 1YGUkl-0004Hg-1C for gllmg-musl@m.gmane.org; Wed, 28 Jan 2015 16:42:03 +0100 Original-Received: (qmail 22049 invoked by uid 550); 28 Jan 2015 15:42:01 -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 22035 invoked from network); 28 Jan 2015 15:42:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=v47aL517vhrT99HLF8mPgt4TgXFBbn+AxaOPnV84bN0=; b=Vxtiz7mc6/Rzmaqu6+bAZ0r2rRFSv9UcZqT7FaMFDqr33e7V9cv70Wd5sZ4ZnJGFrW 2qtYMb71T5kA6VaTJcIuFGq5fuyWGHsXwUDLjRo66Nd8w+GtU/PLRHtv+Ct6uYyUZ0+I 7OxKrJw+EIb9lah4QyRo9Chm10Z/PlEvZcMQJeYDFWqGk5llW6N4mla92lOMAzSa6hdA Su1+99mX/bYI+vROO8OSoQZYa7kE/KZpIVEl36aSAFRfpCOL8l+U+ehH0tQO6dLsgc5+ agKnC7kbhmqyM/mzwkfNQorUdZmJ37KJvAegMD7bAZs040uge1+ZYJbu9Ne8vpDQtWZD +fog== X-Received: by 10.202.228.9 with SMTP id b9mr2458709oih.40.1422459708733; Wed, 28 Jan 2015 07:41:48 -0800 (PST) In-Reply-To: <20150128145410.GH4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6896 Archived-At: 2015-01-28 15:54 GMT+01:00 Rich Felker : > On Tue, Jan 27, 2015 at 11:12:46PM +0100, Daniel Cegie=C5=82ka wrote: >> best regards, >> Daniel > > Thanks. I've been wanting to get this added as well as a getentropy > function (the other API for the same thing). Here is a Theodore Tso version: https://lkml.org/lkml/2014/7/17/474 +wrapper for getentropy(): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= =3Dc6e9d6f38894798696f23c8084ca7edbf16ee895 > >> #include >> #include >> #include "syscall.h" >> >> int getrandom(void *buf, size_t len) >> { >> int ret, pre_errno =3D errno; > > There's no need to save/restore errno here. errno is only meaningful > after a function returns an error code. On success it should not be > inspected and could contain junk. > >> if (len > 256) { >> errno =3D EIO; >> return -1; >> } > > Could you explain the motivation for this part? If you request a large number of bytes you=E2=80=99re going to wait while t= hey are being computed. It make no sense, so getrandom returns an error if the requested is over 256 bytes (__it's worth it thoroughly investigate__). https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= =3Dc6e9d6f38894798696f23c8084ca7edbf16ee895 """ Theodore Tso 2014-07-23 15:11:06 UTC The bug should be fixed if you cherry-pick commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc into 3.15.4+. Please let me know if it doesn't. Why on *earth* are you using /dev/urandom in this way? The nbytes restriction is to prevent an accounting failure since we are now tracking entropy in fractional bits, so when we convert bytes requested into fractional bits, we overflow if someone tries to request more than 32MB. Given that no sane use of /dev/urandom needs more than 256 bytes, this was considered acceptable. """ https://bugzilla.kernel.org/show_bug.cgi?id=3D80981 but I don't have certainty about this. >> do { >> ret =3D syscall(SYS_getrandom, buf, len, 0); >> } while (ret =3D=3D -1 && errno =3D=3D EINTR); > > This would be more efficient (and avoid your errno issue entirely) if > you use __syscall which returns -errcode rather than storing errcode > in errno. It allows the whole loop to be inlined with no function > call. Something like: > > while ((ret =3D __syscall(SYS_getrandom, buf, len, 0)) =3D=3D -EI= NTR); > > Of course there's the question of whether it should loop on EINTR > anyway; I don't know. Also if this can block there's the question of > whether it should be cancellable, but that can be decided later. > > Finally, I wonder if it would make sense to use other fallbacks in the > case where the syscall is not supported -- perhaps the aux vector > AT_RANDOM or even /dev/urandom? (But I'd rather avoid doing anything > that depends on fds, which would make a function that appears to > always-work but actually fails on resource exhaustion.) Thanks, Daniel