setjmp & longjmp at thread start & exit

Matthew Malcomson matthew.malcomson@arm.com
Tue Jun 23 14:42:26 GMT 2020


Hello

The pthread unwinding longjmp/setjmp setup seems a little confusing and
I'd like to ask about the viability of a change.

As I understand it there is a __libc_unwind_longjmp in unwind_stop that
either jumps to the non-interceptable setjmp in __libc_start_main, or to
the setjmp that can be intercepted which was called in the 
pthread_create.c function start_thread.

Is there anything requiring the non-interceptable setjmp in
__libc_start_main?
(Maybe something I don't know around dynamic linking at startup?)
If not, is there any chance of adding the PLT indirection to allow
interception?
I'm asking on the off-chance it's acceptable to the community, since I
do recognise intercepting setjmp & longjmp is not something user code
should usually be doing.


To explain why I'm asking:
I'm trying to handle longjmp and setjmp in a library that maintains a
shadow stack and I'm having trouble with these non-local jumps.
(hwasan -- hardware address sanitizer,
https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html).


To explain why I can't follow what ASAN does (which I expect would be
the first question on most people's minds):

ASAN intercepts all longjmp variants and no setjmp variants.
ASAN clears the entire shadow stack in these interceptors.  HWASAN can't
do the equivalent since it doesn't (in general) have a "valid" byte to
set on the shadow stack -- tags in the pointer used must match tags in
the shadow space.
(There *is* a HWASAN option to have a special match-all tag that's
always valid, but it's not the default and I wouldn't like require such
an approach for userspace santization with a GNU libc).


Thanks for any answers,
Matthew


More information about the Libc-alpha mailing list