[all-commits] [llvm/llvm-project] b380e8: [runtimes][asan] Fix swapcontext interception

[itrofimow via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b380e8b68951776656f286ecd079e2f30981905e
      https://github.com/llvm/llvm-project/commit/b380e8b68951776656f286ecd079e2f30981905e
  Author: Ivan Trofimov <i.trofimow at yandex.ru>
  Date:   2023-04-13 (Thu, 13 Apr 2023)

  Changed paths:
    M compiler-rt/lib/asan/asan_interceptors.cpp
    M compiler-rt/lib/asan/asan_internal.h
    M compiler-rt/lib/asan/asan_linux.cpp
    M compiler-rt/test/asan/TestCases/Linux/swapcontext_test.cpp

  Log Message:
  -----------
  [runtimes][asan] Fix swapcontext interception

Resetting oucp's stack to zero in swapcontext interception is incorrect,
since it breaks ucp cleanup after swapcontext returns in some cases:

Say we have two contexts, A and B, and we swapcontext from A to B, do
some work on Bs stack and then swapcontext back from B to A. At this
point shadow memory of Bs stack is in arbitrary state, but since we
can't know whether B will ever swapcontext-ed to again we clean up it's
shadow memory, because otherwise it remains poisoned and blows in
completely unrelated places when heap-allocated memory of Bs context
gets reused later (see https://github.com/llvm/llvm-project/issues/58633
for example). swapcontext prototype is swapcontext(ucontext* oucp,
ucontext* ucp), so in this example A is oucp and B is ucp, and i refer
to the process of cleaning up Bs shadow memory as ucp cleanup.

About how it breaks:
Take the same example with A and B: when we swapcontext back from B to A
the oucp parameter of swapcontext is actually B, and current trunk
resets its stack in a way that it becomes "uncleanupable" later. It
works fine if we do A->B->A, but if we do A->B->A->B->A no cleanup is
performed for Bs stack after B "returns" to A second time. That's
exactly what happens in the test i provided, and it's actually a pretty
common real world scenario.

Instead of resetting oucp's we make use of uc_stack.ss_flags to mark
context as "cleanup-able" by storing stack specific hash. It should be
safe since this field is not used in [get|make|swap]context functions
and is hopefully never meaningfully used in real-world scenarios (and i
haven't seen any).

Fixes https://github.com/llvm/llvm-project/issues/58633

Reviewed By: vitalybuka

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