From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6406 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 17:05:13 -0400 Message-ID: <20141031210513.GF22465@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> 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 1414789534 26916 80.91.229.3 (31 Oct 2014 21:05:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 21:05:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6419-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 31 22:05:27 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 1XkJNv-0004CU-Mp for gllmg-musl@m.gmane.org; Fri, 31 Oct 2014 22:05:27 +0100 Original-Received: (qmail 3693 invoked by uid 550); 31 Oct 2014 21:05:26 -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 3672 invoked from network); 31 Oct 2014 21:05:25 -0000 Content-Disposition: inline In-Reply-To: <5453EEE3.1040208@amacapital.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6406 Archived-At: On Fri, Oct 31, 2014 at 01:19:47PM -0700, Andy Lutomirski wrote: > On 10/31/2014 09:09 AM, Rich Felker wrote: > > On Fri, Oct 31, 2014 at 10:31:45AM -0400, Richard Gorton wrote: > >> Thank you (and a follow up question) - what code looks at this > >> canary? It is assigned to pthread_self()->canary, but I do not see > >> any code inside musl itself that checks that value? A work in > >> progress? Or does other code check this value? > > > > It's part of the stack-protector feature at the compiler level. gcc, > > clang, and any other compilers that implement this feature generate > > code to read the canary at the start of a function protected by stack > > protector, store it between the saved return address and local > > buffers, and check that it hasn't been clobbered before returning. > > I'm a bit confused by the code now. Is the canary intended to be > per-thread or global? There's a copy in struct pthread. That's a matter of matching the ABI the compiler expects/imposes. For some archs where accessing globals is expensive and accessing TLS is cheap, GCC reads the canary from a fixed thread-pointer-relative address. For others, it accesses the global. > Also, would it make sense for musl to implement getauxval? If so, it > might be nice to do something to avoid inadvertent misuse of the part of > AT_RANDOM value used here. musl does provide getauxval. > 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. > 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. Rich