[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5453FF3C.2030500@amacapital.net>
Date: Fri, 31 Oct 2014 14:29:32 -0700
From: Andy Lutomirski <luto@...capital.net>
To: musl@...ts.openwall.com
Subject: Re: magic constants in some startup code
On 10/31/2014 02:05 PM, Rich Felker wrote:
> 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.
That'll teach me to look at the wrong version of musl.
>
>> 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.
getrandom(2) has the annoying problem that you can't ask it for
best-effort entropy. This caused systemd to add a /dev/urandom fallback
a few days ago (sigh).
Maybe I'll try to get a GRND_BESTEFFORT flag for getrandom into the
kernel. I suppose that a musl getrandom wrapper could emulate that flag
(only) or something on older kernels. Or maybe glibc and musl could
both agree to add some get_sort_of_decent_entropy function based on
AT_RANDOM.
>
>> 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.
Most or all existing getauxval users are unlikely to be using AT_RANDOM,
so doing this without any bloat might be hard.
--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.
