This is an archive of the discontinued LLVM Phabricator instance.

[msan] Block signals in MsanThread::Init
ClosedPublic

Authored by vitalybuka on Nov 5 2021, 8:00 PM.

Details

Summary

If async signal handler called when we MsanThread::Init
signal handler may trigger false reports.
I failed to reproduce this locally for a test.

Diff Detail

Event Timeline

vitalybuka requested review of this revision.Nov 5 2021, 8:00 PM
vitalybuka created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptNov 5 2021, 8:00 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript

What if the signal arrives before MsanThread::Init?
This is what bionic does for hwasan: https://android-review.googlesource.com/c/platform/bionic/+/1134990/

vitalybuka updated this revision to Diff 385632.Nov 8 2021, 2:19 PM

better version

What if the signal arrives before MsanThread::Init?
This is what bionic does for hwasan: https://android-review.googlesource.com/c/platform/bionic/+/1134990/

thanks, done!

vitalybuka planned changes to this revision.Nov 8 2021, 2:20 PM
browneee added inline comments.
compiler-rt/lib/msan/msan_thread.cpp
25 ↗(On Diff #385632)
eugenis added inline comments.Nov 8 2021, 3:11 PM
compiler-rt/lib/msan/msan_thread.cpp
25 ↗(On Diff #385632)

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
73

starting_sigset_ or something like that

vitalybuka updated this revision to Diff 385688.Nov 8 2021, 7:41 PM
vitalybuka marked an inline comment as done.

rebase

eugenis accepted this revision.Nov 9 2021, 5:23 PM

LGTM

compiler-rt/lib/msan/msan_interceptors.cpp
1055

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.

This revision is now accepted and ready to land.Nov 9 2021, 5:23 PM
vitalybuka updated this revision to Diff 386030.Nov 9 2021, 6:23 PM
vitalybuka marked an inline comment as done.

rebase

This revision was landed with ongoing or failed builds.Nov 9 2021, 6:24 PM
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Dec 3 2021, 8:23 AM

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.)

hans added a subscriber: hans.

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.)

Here's a fix: https://reviews.llvm.org/D115057