From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31890 invoked by alias); 27 Oct 2016 17:55:17 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 31879 invoked by uid 89); 27 Oct 2016 17:55:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=secret, concerns X-HELO: mx1.redhat.com Subject: Re: Changing stack protector initialization To: "Carlos O'Donell" , GNU C Library References: <00e0fe87-5ea6-83a8-7e26-2b2af7dd0d0b@redhat.com> <44f539ab-a7f1-da5e-70da-61f66dab9573@redhat.com> From: Florian Weimer Message-ID: <5adadefd-60fc-2f20-a17e-c01a19b96497@redhat.com> Date: Thu, 27 Oct 2016 17:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <44f539ab-a7f1-da5e-70da-61f66dab9573@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00491.txt.bz2 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