[sanitizer] Document AddressSanitizer security considerations (#100937)

Follow-up to #92593.

Also makes #92611, https://github.com/google/sanitizers/issues/1130
obsolete.

clang/docs/AddressSanitizer.rst

@@ -313,6 +313,14 @@ Limitations
   usually expected.
 * Static linking of executables is not supported.
 
+Security Considerations
+=======================
+
+AddressSanitizer is a bug detection tool and its runtime is not meant to be
+linked against production executables. While it may be useful for testing,
+AddressSanitizer's runtime was not developed with security-sensitive
+constraints in mind and may compromise the security of the resulting executable.
+
 Supported Platforms
 ===================
 

clang/docs/HardwareAssistedAddressSanitizerDesign.rst

@@ -262,6 +262,14 @@ than that of AddressSanitizer:
 `1/TG` extra memory for the shadow
 and some overhead due to `TG`-aligning all objects.
 
+Security Considerations
+=======================
+
+HWASAN is a bug detection tool and its runtime is not meant to be
+linked against production executables. While it may be useful for testing,
+HWASAN's runtime was not developed with security-sensitive
+constraints in mind and may compromise the security of the resulting executable.
+
 Supported architectures
 =======================
 HWASAN relies on `Address Tagging`_ which is only available on AArch64.

clang/docs/LeakSanitizer.rst

@@ -43,6 +43,14 @@ To use LeakSanitizer in stand-alone mode, link your program with
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Security Considerations
+=======================
+
+LeakSanitizer is a bug detection tool and its runtime is not meant to be
+linked against production executables. While it may be useful for testing,
+LeakSanitizer's runtime was not developed with security-sensitive
+constraints in mind and may compromise the security of the resulting executable.
+
 Supported Platforms
 ===================
 

clang/docs/MemorySanitizer.rst

@@ -198,6 +198,14 @@ uninstrumented libc. For example, the authors were able to bootstrap
 MemorySanitizer-instrumented Clang compiler by linking it with
 self-built instrumented libc++ (as a replacement for libstdc++).
 
+Security Considerations
+=======================
+
+MemorySanitizer is a bug detection tool and its runtime is not meant to be
+linked against production executables. While it may be useful for testing,
+MemorySanitizer's runtime was not developed with security-sensitive
+constraints in mind and may compromise the security of the resulting executable.
+
 Supported Platforms
 ===================
 

clang/docs/ThreadSanitizer.rst

@@ -135,6 +135,14 @@ Limitations
   flag had been supplied if compiling without ``-fPIC``, and as though the
   ``-pie`` flag had been supplied if linking an executable.
 
+Security Considerations
+-----------------------
+
+ThreadSanitizer is a bug detection tool and its runtime is not meant to be
+linked against production executables. While it may be useful for testing,
+ThreadSanitizer's runtime was not developed with security-sensitive
+constraints in mind and may compromise the security of the resulting executable.
+
 Current Status
 --------------
 

clang/docs/UndefinedBehaviorSanitizer.rst

@@ -256,6 +256,8 @@ Volatile
 The ``null``, ``alignment``, ``object-size``, ``local-bounds``, and ``vptr`` checks do not apply
 to pointers to types with the ``volatile`` qualifier.
 
+.. _minimal-runtime:
+
 Minimal Runtime
 ===============
 
@@ -416,6 +418,15 @@ There are several limitations:
 * Check groups (like ``undefined``) can't be used in suppressions file, only
   fine-grained checks are supported.
 
+Security Considerations
+=======================
+
+UndefinedBehaviorSanitizer's runtime is meant for testing purposes and its usage
+in production environment should be carefully considered from security
+perspective as it may compromise the security of the resulting executable.
+For security-sensitive applications consider using :ref:`Minimal Runtime
+<minimal-runtime>` or trap mode for all checks.
+
 Supported Platforms
 ===================
 

llvm/docs/GwpAsan.rst

@@ -30,14 +30,18 @@ GWP-ASan vs. ASan
 Unlike `AddressSanitizer <https://clang.llvm.org/docs/AddressSanitizer.html>`_,
 GWP-ASan does not induce a significant performance overhead. ASan often requires
 the use of dedicated canaries to be viable in production environments, and as
-such is often impractical.
+such is often impractical. Moreover, ASan's runtime is not developed with
+security consideration in mind, making compiled binaries more vulnerable to
+exploits.
+
+However, GWP-ASan is only capable of finding a subset of the memory issues
+detected by ASan. Furthermore, GWP-ASan's bug detection capabilities are
+only probabilistic. As such, we recommend using ASan over GWP-ASan in testing,
+as well as anywhere else that guaranteed error detection is more valuable than
+the 2x execution slowdown/binary size bloat. For the majority of production
+environments, this impact is too high and security is indispensable, so GWP-ASan
+proves extremely useful.
 
-GWP-ASan is only capable of finding a subset of the memory issues detected by
-ASan. Furthermore, GWP-ASan's bug detection capabilities are only probabilistic.
-As such, we recommend using ASan over GWP-ASan in testing, as well as anywhere
-else that guaranteed error detection is more valuable than the 2x execution
-slowdown/binary size bloat. For the majority of production environments, this
-impact is too high, and GWP-ASan proves extremely useful.
 
 Design
 ======