Date: Fri, 31 Oct 2014 10:18:44 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: magic constants in some startup code 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.