[PATCH] D69045: libhwasan interceptor ABI intercept longjmp/setjmp

[Matthew Malcomson via Phabricator via llvm-commits]

mmalcomson added a comment.

In D69045#2034976 <https://reviews.llvm.org/D69045#2034976>, @jdanek wrote:

> In D69045#2031667 <https://reviews.llvm.org/D69045#2031667>, @mmalcomson wrote:
>
> > (FWIW this particular `setjmp` can be intercepted in glibc 2.31 -- so hopefully as time goes on this will be less of a problem).
>
>
> I am the reporter of the linked GitHub issue. Are you saying that if I just built with glibc 2.31, without any change to clang, then I would not see this instance of the setjmp error?
>
> I believe I am on 2.31 already:


Oh that's interesting -- thanks for pointing it out.

Could you just double check `objdump` your libc -- if it still has a non-ptl symbol then it might be that there was something strange in my testing environment, and that in the wild this is usually non-interceptable.

Interestingly, the reason I added the `__libc_longjmp` interceptor (lines 282-287 in hwasan_interceptors.cpp in the patch above) was because I was seeing a jump buffer mismatch at pthread_exit in the exact opposite way of what you're seeing now (setjmp in libc_start_main was intercepted and longjmp in `unwind_stop` was not).
If you have the time, could you remove that interceptor, rebuild, and re-test in your environment?  The output from that should give some useful information.

When I look into this I'll have to understand when glibc makes that symbol internal, and why my testing environment ended up with a dynamic one.

I still expect the best option would be to avoid non-hwasan jump buffers, as eugenis suggested, but it might be better to have avoid intercepting that symbol if that's what works without a fallback.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69045/new/

https://reviews.llvm.org/D69045