From: Andy Lutomirski <luto@amacapital.net>
To: musl@lists.openwall.com
Subject: Re: magic constants in some startup code
Date: Fri, 31 Oct 2014 14:29:32 -0700 [thread overview]
Message-ID: <5453FF3C.2030500@amacapital.net> (raw)
In-Reply-To: <20141031210513.GF22465@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2014-10-31 21:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 13:31 Richard Gorton
2014-10-31 14:18 ` Rich Felker
2014-10-31 14:31 ` Richard Gorton
2014-10-31 16:09 ` Rich Felker
2014-10-31 20:19 ` Andy Lutomirski
2014-10-31 21:05 ` Rich Felker
2014-10-31 21:29 ` Andy Lutomirski [this message]
2014-10-31 21:39 ` Rich Felker
2014-10-31 22:27 ` Andy Lutomirski
2014-10-31 23:14 ` Rich Felker
2014-11-02 17:17 ` Szabolcs Nagy
2014-11-02 19:10 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5453FF3C.2030500@amacapital.net \
--to=luto@amacapital.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).