[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141031210513.GF22465@brightrain.aerifal.cx>
Date: Fri, 31 Oct 2014 17:05:13 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Re: magic constants in some startup code
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
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.
