This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Changing stack protector initialization


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]