Re: Stepping over longjmp presumably broken for glibc

[Roland McGrath <roland at redhat dot com>]

I'm somewhat concerned that the jmp_buf "fortification" change is going to
break some applications too.  Clearly standard C does not permit any poking
inside of jmp_buf.  However, it's long been known to work and this is the
sort of thing that tends to be exploited by strange language runtime glue
and so forth.  Furthermore, we export macros like JB_PC on i386, giving the
clear impression of what is actually in there and how to use it.

I won't really quarrel with restricting jmp_buf to its standard opaque
semantics.  But in that case I think we should stop exporting macros that
give the impression it's not opaque.  Applications that want to do this
sort of thing can use getcontext instead, since mcontext_t is clearly
intended to be accessible for hardware bits.

There is an argument to be made that this constitutes an incompatible ABI
change and it warrants a new GLIBC_2.4 version for longjmp et al.  I don't
know off hand of affected applications whose old binaries need the
compatibility entry points while those applications get changed to use
setcontext instead.  But I am wary that there may be some.  In this case
I'm not very confident of assertions that they never should have used this
undefined behavior in the past, because it was clearly encouraged by the de
facto API heretofore.


Thanks,
Roland