Re: 5/5 - handle glibc pointer mangling jmp_bufs (x86/x86_64)

[Daniel Jacobowitz <drow@false.org>]

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.

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.
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.  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!

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.

-- 
Daniel Jacobowitz
CodeSourcery