From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6429 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general Subject: Re: magic constants in some startup code Date: Sun, 02 Nov 2014 11:10:54 -0800 Message-ID: <545681BE.1080808@amacapital.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> <20141102171700.GJ10829@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1414955480 12614 80.91.229.3 (2 Nov 2014 19:11:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Nov 2014 19:11:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6442-gllmg-musl=m.gmane.org@lists.openwall.com Sun Nov 02 20:11:13 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 1Xl0YS-0002oE-HH for gllmg-musl@m.gmane.org; Sun, 02 Nov 2014 20:11:12 +0100 Original-Received: (qmail 25844 invoked by uid 550); 2 Nov 2014 19:11: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 25833 invoked from network); 2 Nov 2014 19:11:10 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o1xgplt41LfGJCl4SYLCS1sN0ckkMfo1cZHAqTYicN0=; b=j+IwgvsNnJFtTk9VRUqqFhDzPu/cEnNPZeMwPbSS2pLjU7rSSzYmKZCYQT/CTzDCu3 jVqzIgfuOVGQQnk0ZIf1znYBtaKtosXiWjHtq/wivAcN/ool7MxucBN2/ZITe0/4eMc2 h4wF+J4mkq5kCjgnYbuLv2wuRLkmydFs6tYQrQuqtfKujVC3yqT+0Wq1bxoAeMfW0TAh l8vk0O4OE6re2N2VycxLZNtRj6/8rITD+ze0AnPep1ySC7wyfQS+3St/80M9lKMrXrCy AJAu3ulw7+wVvfTDwOHC3kbl9k0pQ3tzWofAFT4DEeSgLBpeGbRjFNHqOtUyKXqJMzaG cPmQ== X-Gm-Message-State: ALoCoQlrsANV1gzUvadk/jkkBb24q50EadKdDph1glHP8Og4qI721FdM0dgnkVhkPwvLxo3KKxBR X-Received: by 10.70.131.199 with SMTP id oo7mr299688pdb.138.1414955458098; Sun, 02 Nov 2014 11:10:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: <20141102171700.GJ10829@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:6429 Archived-At: On 11/02/2014 09:17 AM, Szabolcs Nagy wrote: > * 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) I don't know the details, but I've heard of this being a real problem on MIPS routers, for example. > >>> 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 > Actually, temp file name generation is probably a decent example of wanting best effort. And getrandom either blocks or fails in very early boot. --Andy