From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29510 invoked by alias); 14 Apr 2008 19:20:28 -0000 Received: (qmail 29477 invoked by uid 22791); 14 Apr 2008 19:20:27 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Apr 2008 19:20:10 +0000 Received: (qmail 30072 invoked from network); 14 Apr 2008 19:20:08 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Apr 2008 19:20:08 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: 5/5 - handle glibc pointer mangling jmp_bufs (x86/x86_64) Date: Mon, 14 Apr 2008 19:24:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sourceware.org References: <200804070336.27192.pedro@codesourcery.com> <200804072325.50739.pedro@codesourcery.com> <20080414185843.GH1968@caradoc.them.org> In-Reply-To: <20080414185843.GH1968@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804142020.07056.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00261.txt.bz2 A Monday 14 April 2008 19:58:43, Daniel Jacobowitz wrote: > On Mon, Apr 07, 2008 at 11:25:50PM +0100, Pedro Alves wrote: > > A Monday 07 April 2008 03:36:27, Pedro Alves wrote: > > > I'm not proposing this to go in, as it will brake glibc's where > > > the pointer mangling is not implemented or is implemented > > > differently. Maybe we could get around this 99% of the > > > times by switching the unmangling algorithm based on glibc's > > > version, although I don't know how to get at glibc's version. > > Darn, and you got my hopes up. I figured you'd come up with a clever > solution to this when I saw the patch subject. > Eh, sorry for not being cleverer :-) Well, my main motivation was to get longjmp working in non-stop mode, I made this patch just so I could test it. > Glibc stores the key in %fs:POINTER_GUARD, from whence we can > retrieve it, as in this patch. It also stores it in > __pointer_chk_guard_local (local to ld.so), and __pointer_chk_guard > (exported, but only on platfroms which do not put it in the TCB). > > If you have an unstripped ld.so, you can retrieve it from that symbol. The key is not enough. There's also a 'rotate right' involved. That seems to have changed through time, as Jan's patch didn't handle the ror, just the xor. > Maybe that is good enough for now, and we can seek a better long-term > solution separately. Also, the location of the guard does not > definitively answer the question of whether it is used to mangle > jmp_bufs. ARM and MIPS don't use it at all. True. I had thought that a solution based on detecting the glibc version and demangling accordingly would be enough. Why isn't it so? Is it plain impossible to extract glibc's version? > Perhaps we should > manually call setjmp to determine if the pointer is mangled? > Heck, from there we could deduce the canary and make this a single > glibc-specific method! > I actually thought of doing this, but I seem to have grown an aversion to the inferior function calls (due to them not being async), so I never tried it, go figure. This would have to be arch dependant, and would have to cope with multiple versions or the algorithm. Does it mangle? Is it a plan xor? It is rotated? By how many bits? Not so much over-complicated tough. > RMS asked us about a way to expose pointer mangling to gdb ages ago. > I believe Jan made this work via libthread_db, which I would prefer to > avoid (remote debugging, for instance). Failing that, I think we're > stuck with the symbol table. As I said, getting at the pointer_guard value is not enough. -- Pedro Alves