Feb 19 2021
Feb 18 2021
Reopening with new revision since previous version has been reverted due to my mistake.
Apologies again for that lazy mistake.
Apologies for the original mistake (which was pretty bad), and the very slow response.
Accidentally created a new revision when attempting to update an existing revision.
Was trying to use arc for first time.
Jan 13 2021
Jan 11 2021
Nov 16 2020
Nov 13 2020
The problem is when hwasan detects a fault accessing a value on the stack in Linux.
What I believe happens is:
Nov 12 2020
May 14 2020
(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:
May 12 2020
According to https://github.com/google/sanitizers/issues/1244, there is a non-interceptable _setjmp in __libc_start_main that is later jumped to in pthread_exit.
It seems to break this approach.
Any idea what to do? Detect that jmpbuf is not a hwasan jmpbuf and bail out? This is happening at the very end of a thread's life, so hopefully it should not matter that the stack in not untagged.
Nov 13 2019
Nov 1 2019
Ping @pcc -- does this change to remove lazy thread initialisation look OK?
Oct 31 2019
Oct 29 2019
Have addressed raised issues.
Oct 25 2019
I've tried to get this working for Android.
Closing given the allocator fallback feature is not being pursued any more.
Oct 21 2019
If late interposition is no longer a supported use-case, does that apply to the pthread use case as well?
Oct 18 2019
Now avoid returning a zero tag when tagging is disabled.
Oct 17 2019
Remove some superfluous semicolons that were causing warnings.
Added a test in the hwasan testsuite.
Oct 16 2019
Oct 15 2019
Run prctl syscall for Android, but ignore EINVAL failures.NOTE: I don't believe this distinguishes between running on a kernel with with the tagged address ABI unconditional or running on a newer kernel or on a kernel with sysctl abi.tagged_addr_disabled=1 (https://android.googlesource.com/kernel/common/+/690c4ca8a5715644370384672f24d95b042db74a/Documentation/arm64/tagged-address-abi.rst)
This is a good point. It appears that PR_GET_TAGGED_ADDR_CTRL works even when abi.tagged_addr_disabled=1, we can use it to tell these two cases apart
Oct 11 2019
Run prctl syscall for Android, but ignore EINVAL failures.