From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6399 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: magic constants in some startup code Date: Fri, 31 Oct 2014 10:18:44 -0400 Message-ID: <20141031141844.GA22465@brightrain.aerifal.cx> References: <45BFC4C3-FA51-49B5-8C58-1C1FC075BD28@cognitive-electronics.com> 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 1414765147 967 80.91.229.3 (31 Oct 2014 14:19:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Oct 2014 14:19:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6412-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 31 15:19:00 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 1XkD2Y-00026h-Le for gllmg-musl@m.gmane.org; Fri, 31 Oct 2014 15:18:58 +0100 Original-Received: (qmail 24161 invoked by uid 550); 31 Oct 2014 14:18:57 -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 24150 invoked from network); 31 Oct 2014 14:18:57 -0000 Content-Disposition: inline In-Reply-To: <45BFC4C3-FA51-49B5-8C58-1C1FC075BD28@cognitive-electronics.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6399 Archived-At: On Fri, Oct 31, 2014 at 09:31:37AM -0400, Richard Gorton wrote: > We're using musl for our processor architecture; as part of doing > the bring-up work, I need to fully understand process launching and > thread creation. Great! > As I'm reading through the source code, I see (more than one) > 'magic' constants that I do not fully understand (musl 1.1.5), and > would like to know 'how and why': > > > src/env/__init_tls.c: > static long long builtin_tls[(sizeof(struct pthread) + 64)/sizeof(long long)]; > > I'm guessing that 64 is an arbitrary 'small' default amount of TLS? > Or is this to hold another specific bit of data? The main idea is to have some minimal amount of default TLS for programs that just use a couple TLS variables, so that they don't have an extra syscall and possible failure path in the startup code. It's also possible (I'd have to re-check) that some of the code that aligns pointers for TLS use is sub-optimal with respect to space and might waste a little bit of overhead in the process of doing alignment. This will not overflow (sizes are checked) but might be able to result in a buffer of the exact needed size being rejected (falling back to allocation) whereas having a little extra room avoids the issue. Something like this was an issue at one time, or at least I didn't demonstrate it not to be an issue, but I'm not sure if it still is or not. > ---- > > src/env/__stack_chk_fail.c > else __stack_chk_guard = (uintptr_t)&__stack_chk_guard * 1103515245; > > the number equates to 0x41c64e6d. > Called from __init_libc as: > __init_ssp((void *)aux[AT_RANDOM]); > The kernel is putting a random number into aux[AT_RANDOM] at process initialization. > Why not just put a predictable arbitrary number into __stack_chk_guard? The reason you don't want a predictable arbitrary number for the stack guard canary is that it makes it easy to bypass stack-protector by including the known number in your overflow payload. The idea in the above code, which really deserves a comment, is to attempt to recover _some_ entropy from the address at which libc is mapped (which hopefully was affected by ASLR) when AT_RANDOM is not available. Modern Linux kernels always give you AT_RANDOM, so this code path would only be taken on an ancient Linux version or a non-Linux host. The magic number 1103515245 is just a LCG, the same as what's used in musl's rand_r() and in the C standard's sample rand(). It serves to mix the bits somewhat, accounting for the likelihood that the mapping address is not very random in some of its bits. None of this is really very effective, but I've left it there because it seems "better than nothing". Rich