This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Changing stack protector initialization
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 27 Oct 2016 13:03:30 -0400
- Subject: Re: Changing stack protector initialization
- Authentication-results: sourceware.org; auth=none
- References: <00e0fe87-5ea6-83a8-7e26-2b2af7dd0d0b@redhat.com>
On 10/27/2016 10:00 AM, Florian Weimer wrote:
> I need a few more pseudo-random bits (32 instead of 16 on 64-bit
> architectures). I talked to some cryptography people and they told
> me to expand the 16-byte secret by hashing it with SHA-256.
>
> This key expansion has to happen both in ld.so (for the stack
> protector and pointer guard) and libc.so (for the new stuff). My
> first attempt failed because doing the initialization in ld.so
> triggers duplication of the new guard variables from libc.so in
> ld.so, and the libc.so variables are never initialized. (This is
> very confusing to GDB, which does not tell you that you have two
> variables with the same name at different addresses.)
Could you explain this in a bit more detail?
> I think the best approach is to duplicate the initialization code and
> run it twice, once based on the _dl_random value, and once using
> getauxval (AT_RANDOM). The other alternative would be to put the
> values computed by rtld into rtld_global or some similar place and
> use those values to initialize the libc.so variables, but this wastes
> 16 bytes in the data segment per process. (I need to make a copy so
> that the variable access does not go through the GOT.)
I don't like the idea of multiple initialization, it leads to difficult
to answer ordering questions. It is much easier conceptually to initialize
once and then copy the result.
> Is there another option to implement this?
Yes, initialize once, and copy the result as required?
--
Cheers,
Carlos.