[PATCH] Add support for -fsanitize-blacklist and default blacklists for DFSan

[Peter Collingbourne]

    - Add some ABI list documentation and add DFSan to the toctree

Hi kcc,

http://llvm-reviews.chandlerc.com/D1346

CHANGE SINCE LAST DIFF
  http://llvm-reviews.chandlerc.com/D1346?vs=3338&id=3393#toc

Files:
  docs/DataFlowSanitizer.rst
  docs/index.rst
  lib/CodeGen/BackendUtil.cpp
  lib/Driver/SanitizerArgs.cpp

Index: docs/DataFlowSanitizer.rst
===================================================================
--- docs/DataFlowSanitizer.rst
+++ docs/DataFlowSanitizer.rst
@@ -2,6 +2,11 @@
 DataFlowSanitizer
 =================
 
+.. toctree::
+   :hidden:
+
+   DataFlowSanitizerDesign
+
 .. contents::
    :local:
 
@@ -28,6 +33,82 @@
 For further information about each function, please refer to the header
 file.
 
+ABI List
+--------
+
+DataFlowSanitizer uses a list of functions known as an ABI list to decide
+whether a call to a specific function should use the operating system's native
+ABI or whether it should use a variant of this ABI that also propagates labels
+through function parameters and return values.  The ABI list file also controls
+how labels are propagated in the former case.  DataFlowSanitizer comes with a
+default ABI list which is intended to eventually cover the glibc library on
+Linux but it may become necessary for users to extend the ABI list in cases
+where a particular library or function cannot be instrumented (e.g. because
+it is implemented in assembly or another language which DataFlowSanitizer does
+not support) or a function is called from a library or function which cannot
+be instrumented.
+
+DataFlowSanitizer's ABI list file is a :doc:`SanitizerSpecialCaseList`.
+The pass treats every function in the ``uninstrumented`` category in the
+ABI list file as conforming to the native ABI.  Unless the ABI list contains
+additional categories for those functions, a call to one of those functions
+will produce a warning message, as the labelling behavior of the function
+is unknown.  The other supported categories are ``discard``, ``functional``
+and ``custom``.
+
+* ``discard`` -- To the extent that this function writes to (user-accessible)
+  memory, it also updates labels in shadow memory (this condition is trivially
+  satisfied for functions which do not write to user-accessible memory).  Its
+  return value is unlabelled.
+* ``functional`` -- Like ``discard``, except that the label of its return value
+  is the union of the label of its arguments.
+* ``custom`` -- Instead of calling the function, a custom wrapper ``__dfsw_F``
+  is called, where ``F`` is the name of the function.  This function may wrap
+  the original function or provide its own implementation.  This category is
+  generally used for uninstrumentable functions which write to user-accessible
+  memory or which have more complex label propagation behavior.  The signature
+  of ``__dfsw_F`` is based on that of ``F`` with each argument having a
+  label of type ``dfsan_label`` appended to the argument list.  If ``F``
+  is of non-void return type a final argument of type ``dfsan_label *``
+  is appended to which the custom function can store the label for the
+  return value.  For example:
+
+.. code-block:: c++
+
+  void f(int x);
+  void __dfsw_f(int x, dfsan_label x_label);
+
+  void *memcpy(void *dest, const void *src, size_t n);
+  void *__dfsw_memcpy(void *dest, const void *src, size_t n,
+                      dfsan_label dest_label, dfsan_label src_label,
+                      dfsan_label n_label, dfsan_label *ret_label);
+
+If a function defined in the translation unit being compiled belongs to the
+``uninstrumented`` category, it will be compiled so as to conform to the
+native ABI.  Its arguments will be assumed to be unlabelled, but it will
+propagate labels in shadow memory.
+
+For example:
+
+.. code-block:: none
+
+  # main is called by the C runtime using the native ABI.
+  fun:main=uninstrumented
+  fun:main=discard
+
+  # malloc only writes to its internal data structures, not user-accessible memory.
+  fun:malloc=uninstrumented
+  fun:malloc=discard
+
+  # tolower is a pure function.
+  fun:tolower=uninstrumented
+  fun:tolower=functional
+
+  # memcpy needs to copy the shadow from the source to the destination region.
+  # This is done in a custom function.
+  fun:memcpy=uninstrumented
+  fun:memcpy=custom
+
 Example
 =======
 
Index: docs/index.rst
===================================================================
--- docs/index.rst
+++ docs/index.rst
@@ -21,6 +21,7 @@
    AddressSanitizer
    ThreadSanitizer
    MemorySanitizer
+   DataFlowSanitizer
    SanitizerSpecialCaseList
    Modules
    FAQ
Index: lib/CodeGen/BackendUtil.cpp
===================================================================
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -208,7 +208,10 @@
 
 static void addDataFlowSanitizerPass(const PassManagerBuilder &Builder,
                                      PassManagerBase &PM) {
-  PM.add(createDataFlowSanitizerPass());
+  const PassManagerBuilderWrapper &BuilderWrapper =
+      static_cast<const PassManagerBuilderWrapper&>(Builder);
+  const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
+  PM.add(createDataFlowSanitizerPass(CGOpts.SanitizerBlacklistFile));
 }
 
 void EmitAssemblyHelper::CreatePasses(TargetMachine *TM) {
Index: lib/Driver/SanitizerArgs.cpp
===================================================================
--- lib/Driver/SanitizerArgs.cpp
+++ lib/Driver/SanitizerArgs.cpp
@@ -295,6 +295,9 @@
     BlacklistFile = "msan_blacklist.txt";
   else if (Kind & NeedsTsanRt)
     BlacklistFile = "tsan_blacklist.txt";
+  else if (Kind & NeedsDfsanRt)
+    BlacklistFile = "dfsan_abilist.txt";
+
   if (BlacklistFile) {
     SmallString<64> Path(D.ResourceDir);
     llvm::sys::path::append(Path, BlacklistFile);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D1346.2.patch
Type: text/x-patch
Size: 5468 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130812/d482bf54/attachment.bin>