Re: longjmp handling vs. glibc LD_POINTER_GUARD problems

[Daniel Jacobowitz <drow@false.org>]

On Wed, May 14, 2008 at 02:26:58PM -0700, David Miller wrote:
> I think you can treat this the same way we treat the signal frame
> layout.  It's something undocumented but effectively fixed in stone.
> 
> If glibc ever changed the offset within the thread struct for this
> cookie, so many binaries would break.  So it is very likely the value
> will stay the same for the forseeable future.

I don't think that's true, is it?  There's two cookies, only one of
them is exposed to GCC, and glibc uses internal macros to protect the
contents of a jmp_buf which are not necessarily the same as those used
by GCC.

e.g. gcc uses xor with %fs:0x14 on i386-linux.  That's
__stack_chk_guard and jmp_buf uses PTR_MANGLE -> __pointer_chk_guard.

Many architectures don't expose either variable.

-- 
Daniel Jacobowitz
CodeSourcery