If async signal handler called when we MsanThread::Init
signal handler may trigger false reports.
I failed to reproduce this locally for a test.
Details
- Reviewers
eugenis browneee - Commits
- rGf2c2292fa801: [msan] Block signals in MsanThread::Init
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
37,990 ms | x64 debian > libFuzzer.libFuzzer::entropic-scale-per-exec-time.test |
Event Timeline
What if the signal arrives before MsanThread::Init?
This is what bionic does for hwasan: https://android-review.googlesource.com/c/platform/bionic/+/1134990/
compiler-rt/lib/msan/msan_thread.cpp | ||
---|---|---|
25 | Would the same fix be applicable for DFSan? |
compiler-rt/lib/msan/msan_thread.cpp | ||
---|---|---|
25 | I think so. We need to prevent signals from running on the new thread stack and tls before they are ready. Another option would be to always allocate stacks for threads ourselves in the parent thread, but the current approach is simpler. Not sure about including <signal.h> here. It should go in msan_linux.cpp, or even in sanitizer_common_posix.cpp if it was reused in dfsan. | |
compiler-rt/lib/msan/msan_thread.h | ||
72 | starting_sigset_ or something like that |
LGTM
compiler-rt/lib/msan/msan_interceptors.cpp | ||
---|---|---|
1055 ↗ | (On Diff #385688) | I'd prefer an API where the save location is passed as a construction argument. ScopedBlockSignals block(&t->starting_sigset_); Or change the API to explicit block() and release() and move the entire object to MsanThread (call release in the parent and the child explicitly). That way MSanThread does not need to know about __sanitizer_sigset_t. Anyway, it's just an aesthetic preference. Up to you. |
FYI, this broke running tests in sandboxes processes with msan for us (https://crbug.com/1276113). We're still looking into options, but here's an early heads-up.
(…mostly in case others bisect something to this change.)
starting_sigset_ or something like that