[all-commits] [llvm/llvm-project] 858eb8: [TSan][Darwin] Avoid crashes due to interpreting n...

[Julian Lettner via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 858eb8fc11e2e683ef1cef956ac102bfc5f0a1a8
      https://github.com/llvm/llvm-project/commit/858eb8fc11e2e683ef1cef956ac102bfc5f0a1a8
  Author: Julian Lettner <julian.lettner at apple.com>
  Date:   2021-11-30 (Tue, 30 Nov 2021)

  Changed paths:
    M compiler-rt/lib/tsan/rtl/tsan_platform_mac.cpp

  Log Message:
  -----------
  [TSan][Darwin] Avoid crashes due to interpreting non-zero shadow content as a pointer

We would like to use TLS to store the ThreadState object (or at least a
reference ot it), but on Darwin accessing TLS via __thread or manually
by using pthread_key_* is problematic, because there are several places
where interceptors are called when TLS is not accessible (early process
startup, thread cleanup, ...).

Previously, we used a "poor man's TLS" implementation, where we use the
shadow memory of the pointer returned by pthread_self() to store a
pointer to the ThreadState object.

The problem with that was that certain operations can populate shadow
bytes unbeknownst to TSan, and we later interpret these non-zero bytes
as the pointer to our ThreadState object and crash on when dereferencing
the pointer.

This patch changes the storage location of our reference to the
ThreadState object to "real" TLS.  We make this work by artificially
keeping this reference alive in the pthread_key destructor by resetting
the key value with pthread_setspecific().

This change also fixes the issue were the ThreadState object is
re-allocated after DestroyThreadState() because intercepted functions
can still get called on the terminating thread after the
THREAD_TERMINATE event.

Radar-Id: rdar://problem/72010355

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D110236