Changing stack protector initialization

[Florian Weimer]

On 10/27/2016 07:03 PM, Carlos O'Donell wrote:
> 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?

It's a bit complicated.  I've put the patch on the branch fw/heap-protector.

The branch should build just fine, and the malloc/tst-mallocstate test 
passes.  However, it should fail.

If you set a breakpoint in the middle of do_test, after the 
initialization (say, tst-mallocstate.c:486), you have this situation:

(gdb) print __malloc_header_guard
$2 = 1248978169008729616
(gdb) print &__malloc_header_guard
$5 = (size_t *) 0x555555779128 <__malloc_header_guard>

But look at the disassembly of malloc_usable_size.  It contains:

    0x00007ffff7cd5355 <+37>:    xor    0x322114(%rip),%rax        # 
0x7ffff7ff7470 <__malloc_header_guard>

And of course:

(gdb) print *(size_t *)0x7ffff7ff7470
$6 = 0

Notice the difference address of the variable:

(gdb) info symb 0x7ffff7ff7470
__malloc_header_guard in section .bss of ./libc.so.6
(gdb) info symb 0x555555779128
__malloc_header_guard in section .bss of 
/home/fweimer/src/gnu/glibc/build/elf/ld-linux-x86-64.so.2

I hope this allows you to reproduce the issue easily.

I'll try to propagate the cookie values through GLRO variables.  I do 
not want to access GLRO directly in the malloc code due to performance 
concerns.

Thanks,
Florian