[HWASan] Remove __libc_longjmp interceptor.

[morehouse]

Summary

On Linux __libc_longjmp is called from pthread_exit, and uses a
jmp_buf that was initialized by _setjmp called from
__libc_start_main. The _setjmp call does not use the PLT, so we
cannot intercept it.

The result is a mismatch in jmp_buf format, since _setjmp uses
glibc's format while our __libc_longjmp interceptor uses HWASan's
format. Removing the __libc_longjmp interceptor avoids the mismatch.

See discussion on https://reviews.llvm.org/D69045.

Fixes https://github.com/google/sanitizers/issues/1244.

[eugenis]

From the discussion in D69045, I see that in older glibc versions setjmp in thread creation was intercepted, and we had to intercept this __libc_longjmp to match, but that is no longer the case. If there are no good solutions that work everywhere, then supporting 2.31+ is OK I guess (it's 1.5 years old by now). Could you see if we could detect hwasan vs libc jmpbuf format easily though, and forward to libc in the latter case?

Is there a test that is fixed by this change?

[morehouse]

In D109699#2998405, @eugenis wrote:

From the discussion in D69045, I see that in older glibc versions setjmp in thread creation was intercepted, and we had to intercept this __libc_longjmp to match, but that is no longer the case. If there are no good solutions that work everywhere, then supporting 2.31+ is OK I guess (it's 1.5 years old by now). Could you see if we could detect hwasan vs libc jmpbuf format easily though, and forward to libc in the latter case?

It is tricky. The hwasan jmpbuf must be no larger than the libc one, and they're currently the same size. So we can't add an extra magic field to distinguish them.

Maybe we could put a magic in the top byte of the saved PC? We never expect the PC to be tagged, right?

I can test this locally for x86. I don't have a great way to do it for aarch64, but I could push it and check the bots.

Is there a test that is fixed by this change?

Without this change the pthread_exit.c test fails locally with my x86 setjmp/longjmp patch.

[morehouse]

Actually it looks like libc only uses int __mask_was_saved as a bool. So we could put a magic in the other 31 bits.

[morehouse]

See https://reviews.llvm.org/D109787 for the magic approach.

[morehouse]

Abandoning in favor of https://reviews.llvm.org/D109787

compiler-rt/lib/hwasan/hwasan_interceptors.cpp

 INTERCEPTOR(void, siglongjmp, __hw_sigjmp_buf env, int val) {
   if (env[0].__mask_was_saved)
     // Restore the saved signal mask.
     (void)sigprocmask(SIG_SETMASK, &env[0].__saved_mask,
                       (__hw_sigset_t *)0);
   InternalLongjmp(env[0].__jmpbuf, val);
 }
 
-// Required since glibc libpthread calls __libc_longjmp on pthread_exit, and
-// _setjmp on start_thread.  Hence we have to intercept the longjmp on
-// pthread_exit so the __hw_jmp_buf order matches.
-INTERCEPTOR(void, __libc_longjmp, __hw_jmp_buf env, int val) {
-  InternalLongjmp(env[0].__jmpbuf, val);
-}
-
 INTERCEPTOR(void, longjmp, __hw_jmp_buf env, int val) {
   InternalLongjmp(env[0].__jmpbuf, val);
 }
 #undef SIG_BLOCK
 #undef SIG_SETMASK
 
 #endif // HWASAN_WITH_INTERCEPTORS && __aarch64__