From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114952 invoked by alias); 27 Oct 2016 17:03:36 -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 114935 invoked by uid 89); 27 Oct 2016 17:03:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=secret X-HELO: mail-qk0-f173.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=BV3JERL8wi/MUad0oWdC3XK+7zcooVzhh652RIJumrI=; b=Cdt1xu5RyWSuggDpNJa/dNKtz22yu7MflNeZca8dqHvQG4hNDOX4SNmo5K+z4Kea5d QwI3xV/3x7y1pxMBc7kcqG2+6Oxbxlk7qot9ViPTfXtCkKbjvygdw7VxqSEIlD6y/2BO +njKxxVAm1nzxIlFhzck67sjK3+wQnowlXlA99Gz8Zj4uU8euCmZm0xgAFJZ7bsWi3Dg qUP/WsnYm1ADgsgTZKqWpntWh3jxb1lS3RkuX1FsyJ+JJjYeA+lWVWmhELEwQnc8e1QA vNgwUFI1nuGowUxLjL6jaeqBXHiaAF3u8rI+V3CeGrmgjJEaLO/2c2wpXSIDd4RrD+9R 4vLQ== X-Gm-Message-State: ABUngvd7Kalk+E76xHmy84jhEHFasgPwR7hHEVMGuKFEH+5bOvI4WWuM4IvHzBsLv3n8lLcw X-Received: by 10.55.41.209 with SMTP id p78mr7960256qkp.282.1477587812813; Thu, 27 Oct 2016 10:03:32 -0700 (PDT) Subject: Re: Changing stack protector initialization To: Florian Weimer , GNU C Library References: <00e0fe87-5ea6-83a8-7e26-2b2af7dd0d0b@redhat.com> From: Carlos O'Donell Message-ID: <44f539ab-a7f1-da5e-70da-61f66dab9573@redhat.com> Date: Thu, 27 Oct 2016 17:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <00e0fe87-5ea6-83a8-7e26-2b2af7dd0d0b@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00490.txt.bz2 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.