From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6409 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: Fri, 31 Oct 2014 15:27:37 -0700 Message-ID: <54540CD9.3070901@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> 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 1414794485 6809 80.91.229.3 (31 Oct 2014 22:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 22:28:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6422-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 31 23:27:58 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 1XkKfj-0005xR-MX for gllmg-musl@m.gmane.org; Fri, 31 Oct 2014 23:27:55 +0100 Original-Received: (qmail 20166 invoked by uid 550); 31 Oct 2014 22:27:53 -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 20158 invoked from network); 31 Oct 2014 22:27:52 -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=z1onusec2Go8Xd/b52eaSl+l2A6pzzzZgvBN7hcGOlI=; b=bmzkmlKfGtpc3UDYXZBkuvKniygREyr0ImCJNgQ4GaCZ2csJFXTogSwP3gQ7Dp1ENT SDvUv2igTNOUva6lgtsiHpRAbcrjXhzqFfudA+9Ib6bYOx++yPad4oS7zW2FhBrG3P9b RpaPWnlQ3DeptPHjbDPDkmL3JRtUPgnLNqbEnmGf/5Xk1LhRz/0BhBzECegLjbI9rspR nB338gseCDWZFuZKqTUgT5LXCb9zkV8b056onfUdQZBWwjO/Zk3Y69MHVZ7//tNRGd6M MZfb7LEptUeUTZVqLAXIkBOZlWaI/Z6UG89ZKRUz8MmZShSRZy0SyRoifylgaDkIz7bo cDAg== X-Gm-Message-State: ALoCoQmP2TsP0IDcG6HS20ofZJGdF5R3onRvelhgI4Snw+/Kdpt0Q/3wvy8BTY4mAcyWWPFKnwjI X-Received: by 10.68.129.69 with SMTP id nu5mr26377764pbb.51.1414794460738; Fri, 31 Oct 2014 15:27:40 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: <20141031213914.GG22465@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6409 Archived-At: On 10/31/2014 02:39 PM, Rich Felker wrote: > On Fri, Oct 31, 2014 at 02:29:32PM -0700, Andy Lutomirski wrote: >>>> For example, musl could implement a trivial DRBG seeded by AT_RANDOM and >>>> replace the AT_RANDOM data with the first output from the DRBG at >>>> startup. Then getauxval users are safe and musl can also have a stream >>>> of decent random numbers for internal use. >>> >>> This imposes a large code size cost in the mandatory startup code even >>> on programs that have no interest in AT_RANDOM (99% or more). Instead, >>> the first call to getauxval could do this, though, but I'm not sure >>> it's a good approach anyway. Linux has added the getrandom syscall >>> which can provide the BSD getentropy function or the more featureful >>> getrandom API, so using getauxval(AT_RANDOM) seems like a bad idea. >>> Even if we avoided reuse of the same data that went into the canary, >>> there's no way for callers using getauxval(AT_RANDOM) to tell whether >>> some other library code in the same process has already consumed >>> entropy from AT_RANDOM, so using it is not library-safe. It seems like >>> we should try to discourage use of getauxval(AT_RANDOM) as an entropy >>> source rather than giving false hope that it's safe. >> >> getrandom(2) has the annoying problem that you can't ask it for >> best-effort entropy. This caused systemd to add a /dev/urandom fallback >> a few days ago (sigh). > > 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. > >> 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. 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(); --Andy > >>>> If you think this is a good idea, I could implement it. The main >>>> downside would be that it'll require some crypto primitive. There's >>>> already a SHA-256 implementation in musl that could be reused, but it >>>> would be a bit unfortunate to pull it in to all musl-linked static binaries. >>> >>> Yes, code size is a concern, but it could be tucked away as a >>> dependency of other functions instead of being a dependency of the >>> startup code. >> >> Most or all existing getauxval users are unlikely to be using AT_RANDOM, >> so doing this without any bloat might be hard. > > Yes, this is a good point. > > Rich >