From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130981 invoked by alias); 27 Oct 2016 14:00:39 -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 129189 invoked by uid 89); 27 Oct 2016 14:00:33 -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=UD:libc.so, libcso, libc.so, Hx-languages-length:1194 X-HELO: mx1.redhat.com To: GNU C Library From: Florian Weimer Subject: Changing stack protector initialization Message-ID: <00e0fe87-5ea6-83a8-7e26-2b2af7dd0d0b@redhat.com> Date: Thu, 27 Oct 2016 14:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00487.txt.bz2 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.) 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.) Is there another option to implement this? Thanks, Florian