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

[Pedro Alves]

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