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

[Daniel Jacobowitz <drow@false.org>]

On Mon, Apr 14, 2008 at 08:20:06PM +0100, Pedro Alves wrote:
> 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.

Yes, that does seem to be new (2007-02-01).

You could do this even more evilly.  Do it by setting a breakpoint on
setjmp, recording information before and after, and then deleting the
breakpoint until we re-run.  Yes, this is getting excessive.  But
there shouldn't ever be a call to longjmp without a call to setjmp
first.

> > 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?

There's no interface for it.  It's there, but only in the unstripped
symbol table like __pointer_chk_guard:

(gdb) x/s &__libc_version
0x2aaaab8f8cd8 <__libc_version>:         "2.7"

That's not very fine-grained, either.  And feature tests are more
robust than version tests, since they'd detect an unsupported
algorithm.  I admit that the feature test is much harder...

-- 
Daniel Jacobowitz
CodeSourcery