glibc can call SafeStack instrumented code even after the last pthread
data destructor has run. Delay cleaning-up unsafe stacks for threads
until the thread is dead by having future threads clean-up prior threads
stacks.
Details
Diff Detail
- Repository
- rCRT Compiler Runtime
- Build Status
Buildable 21293 Build 21293: arc lint + arc unit
Event Timeline
lib/safestack/safestack.cc | ||
---|---|---|
162 | Wasn't sure if I was allowed to use libpthread from a runtime. I think I could replace the mutex with the __atomic_exchange() built-in if I need to. |
lib/safestack/safestack.cc | ||
---|---|---|
162 | We are using it already, so it should be fine. | |
202 | You are trying to append to the end of temp_stacks list. But if we managed to destroy all pending stacks, then stackp points to temp_stacks itself, which is a local variable, and this store is dead. |
Random thought: isn't the introduction of malloc here (as opposed to an OS backed alternative like mmap) gonna mess compatibility with other Sanitizers that intercept it? (thinking of Scudo which is currently compatible with SafeStack but I haven't tested).
malloc() would only be called during thread destruction, so it doesn't seem like there should be an issue unless malloc() causes a thread to destruct and even then this function shouldn't re-enter because of the order of when pthread_setspecific() is called. Perhaps I'm just failing to imagine a situation under which this could be an issue?
Wasn't sure if I was allowed to use libpthread from a runtime. I think I could replace the mutex with the __atomic_exchange() built-in if I need to.