[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5453EEE3.1040208@amacapital.net>
Date: Fri, 31 Oct 2014 13:19:47 -0700
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: magic constants in some startup code
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.
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.
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.
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.
--Andy
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.
