Re: Re: magic constants in some startup code

[Rich Felker <dalias@libc.org>]

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