From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-8694-listarch-libc-hacker=sources.redhat.com@sourceware.org>
Received: (qmail 24115 invoked by alias); 20 Dec 2005 23:58:18 -0000
Received: (qmail 24098 invoked by uid 22791); 20 Dec 2005 23:58:17 -0000
X-Spam-Check-By: sourceware.org
Received: from gateway.sf.frob.com (HELO gateway.sf.frob.com) (64.81.54.130)
    by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 20 Dec 2005 23:58:16 +0000
Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id 811E1357B; Tue, 20 Dec 2005 15:58:13 -0800 (PST)
Received: by magilla.sf.frob.com (Postfix, from userid 5281)
	id 1EED31809B6; Tue, 20 Dec 2005 15:58:13 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Steven Munroe <munroesj@us.ibm.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Ulrich Drepper <drepper@redhat.com>,
	GNU libc hacker <libc-hacker@sources.redhat.com>
Subject: Re: things to do for arch maintainers
In-Reply-To: Steven Munroe's message of  Tuesday, 20 December 2005 18:30:48 -0600 <43A8A238.4060609@us.ibm.com>
X-Antipastobozoticataclysm: Bariumenemanilow
Message-Id: <20051220235813.1EED31809B6@magilla.sf.frob.com>
Date: Tue, 20 Dec 2005 23:58:00 -0000
Mailing-List: contact libc-hacker-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-hacker-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sourceware.org>
List-Help: <mailto:libc-hacker-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-hacker-owner@sourceware.org
X-SW-Source: 2005-12/txt/msg00035.txt.bz2

> This may be appropriate because powerpc does not have a pc relative 
> reference to access __pointer_chk_guard_local and access via the 
> .got/.toc will fail if access is attemped before the got/toc are 
> relocated. But I wanted to verify this.

If you cannot access it safely in the first _dl_catch_error call in
startup, then leave the macros undefined.  I think the ld.so bootstrap
relocation will be complete before it's ever used.

> It is not clear what this change is really for, so it is difficult to 
> determine what is intended or required.

They make it harder to exploit buffer overruns to write useful addresses
into jmp_buf's PC values and have those result in attacker-chosen jumps.


Thanks,
Roland