[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141031141844.GA22465@brightrain.aerifal.cx>
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.
