From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6410 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: magic constants in some startup code Date: Fri, 31 Oct 2014 19:14:58 -0400 Message-ID: <20141031231458.GH22465@brightrain.aerifal.cx> 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> 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 1414797328 16181 80.91.229.3 (31 Oct 2014 23:15:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 23:15:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6423-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 01 00:15:18 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 1XkLPV-00048y-6L for gllmg-musl@m.gmane.org; Sat, 01 Nov 2014 00:15:13 +0100 Original-Received: (qmail 19959 invoked by uid 550); 31 Oct 2014 23:15:11 -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 19947 invoked from network); 31 Oct 2014 23:15:11 -0000 Content-Disposition: inline In-Reply-To: <54540CD9.3070901@amacapital.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6410 Archived-At: 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. > >> Maybe I'll try to get a GRND_BESTEFFORT flag for getrandom into the > >> kernel. I suppose that a musl getrandom wrapper could emulate that flag > >> (only) or something on older kernels. Or maybe glibc and musl could > >> both agree to add some get_sort_of_decent_entropy function based on > >> AT_RANDOM. > > > > Really you can provide perfecty good random numbers for cryptographic > > purposes with just AT_RANDOM as a seen and a proper csprng. My > > understanding of the motivation for fancier stuff is a (misguided, > > IMO) idea that sequences in the parent and child should be independent > > after fork. > > 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? > I am, however, quite convinced that different sequences after fork is > important. Otherwise you can have catastrophic failures, e.g. if you do > fork(); compute_dsa_signature(); I agree that this is a catastrophic failure; I just disagree on the cause. I think it's a bug to be doing anything after fork execept exec (or something to prepare for exec). By keeping a copy of the parent's address space while continuing to run, you expose yourself to all sorts of possible information-leak issues. It's really hard to arrange for the address space not to contain secrets at the time of fork. And in multithreaded programs, it's simply UB to do anything but calling async-signal-safe functions in the child after fork. I'd still like to avoid duplicate sequences just from a standpoint of hardening, but I the programs depending on this are already failing to follow good practices. Rich