From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6427 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: magic constants in some startup code Date: Sun, 2 Nov 2014 18:17:01 +0100 Message-ID: <20141102171700.GJ10829@port70.net> References: <45BFC4C3-FA51-49B5-8C58-1C1FC075BD28@cognitive-electronics.com> <20141031141844.GA22465@brightrain.aerifal.cx> <8B3E5DDE-2691-4377-8934-362ACC7BEA69@cognitive-electronics.com> <20141031160913.GC22465@brightrain.aerifal.cx> <5453EEE3.1040208@amacapital.net> <20141031210513.GF22465@brightrain.aerifal.cx> <5453FF3C.2030500@amacapital.net> <20141031213914.GG22465@brightrain.aerifal.cx> <54540CD9.3070901@amacapital.net> <20141031231458.GH22465@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 1414948641 8152 80.91.229.3 (2 Nov 2014 17:17:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 17:17:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6440-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 02 18:17:14 2014 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 1XkymA-0002zu-7q for gllmg-musl@m.gmane.org; Sun, 02 Nov 2014 18:17:14 +0100 Original-Received: (qmail 12145 invoked by uid 550); 2 Nov 2014 17:17:13 -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 12128 invoked from network); 2 Nov 2014 17:17:12 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141031231458.GH22465@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6427 Archived-At: * Rich Felker [2014-10-31 19:14:58 -0400]: > On Fri, Oct 31, 2014 at 03:27:37PM -0700, Andy Lutomirski wrote: > > > Is best-effort ever useful? My feeling is that either you need > > > cryptographic quality entropy, in which case it's not acceptable to > > > get something fake, or you don't, in which case you can use something > > > like the clock. Maybe I'm misunderstanding what you mean by > > > best-effort. My impression was that getrandom was equivalent to > > > /dev/urandom, not the tin-foil-hattery that is /dev/random. > > > > The clock really sucks for entropy. There are systems on which it's > > entirely plausible that two different processes will start in rapid > > succession and get exactly the same value out of the clock. > > Are you sure? AFAIK Linux has at least microsecond resolution on all > major archs and nanosecond on x86 and some other important ones, and > fork takes over 1000ns and exec a lot more still. So I don't see how > you could get duplicates. > i'm interested in why clock might be bad source of entropy too (it is not usable for key generation and there are some devices with broken clock, but otherwise it should be a good source to avoid collisions in some name space) > > The problems with AT_RANDOM and with getrandom(2) involve early boot. > > Newer kernels (especially on ARM, apparently) can boot quickly enough > > that the RNG is in terribly shape when userspace starts. AT_RANDOM will > > contain something, regardless, but it might have rather little entropy. > > getrandom(2) will refuse to operate at all until the kernel thinks it > > has 128 bits or so of entropy. > > > > So, if you want entropy at process start, AT_RANDOM is the best you can > > do. But you should seed a per-process csprng with it if you can avoid > > it, or at least you should reseed with getrandom, since the kernel RNG > > will eventually end up being cryptographically secure. > > > > IOW, there isn't really a great solution here. > > Well, this sounds like a good reason not to have code that depends on > entropy in pid 1.... :-) > > Maybe there are situations here where you'd want best-effort, but I > can't think of any except initializing the stack protector canary > (which already uses AT_RANDOM) for init or other very-early processes > which should not be exposed to any input, much less untrusted input. > And on a machine with insufficient initial entropy, the first thing > the init sequence does should be getting the hardware to get you some > entropy, no? > if early boot here means init then i dont think it's reasonable to assume good entropy at that point anyway entropy quality should not be libc resposibility at all, libc uses whatever the kernel gives it used to be infeasible to get new entropy from the kernel on demand without introducing difficult to handle failure paths, but in new kernels eg the temp file name generation could easily use getrandom and then the quailty is kernel side issue