granicus.if.org Git - clang/blob - docs/ControlFlowIntegrity.rst

   1 ======================
   2 Control Flow Integrity
   3 ======================
   4
   5 .. toctree::
   6    :hidden:
   7
   8    ControlFlowIntegrityDesign
   9
  10 .. contents::
  11    :local:
  12
  13 Introduction
  14 ============
  15
  16 Clang includes an implementation of a number of control flow integrity (CFI)
  17 schemes, which are designed to abort the program upon detecting certain forms
  18 of undefined behavior that can potentially allow attackers to subvert the
  19 program's control flow. These schemes have been optimized for performance,
  20 allowing developers to enable them in release builds.
  21
  22 To enable Clang's available CFI schemes, use the flag ``-fsanitize=cfi``.
  23 As currently implemented, CFI relies on link-time optimization (LTO); so it is
  24 required to specify ``-flto``, and the linker used must support LTO, for example
  25 via the `gold plugin`_. To allow the checks to be implemented efficiently,
  26 the program must be structured such that certain object files are compiled
  27 with CFI enabled, and are statically linked into the program. This may
  28 preclude the use of shared libraries in some cases.
  29
  30 Clang currently implements forward-edge CFI for member function calls and
  31 bad cast checking. More schemes are under development.
  32
  33 .. _gold plugin: http://llvm.org/docs/GoldPlugin.html
  34
  35 Forward-Edge CFI for Virtual Calls
  36 ----------------------------------
  37
  38 This scheme checks that virtual calls take place using a vptr of the correct
  39 dynamic type; that is, the dynamic type of the called object must be a
  40 derived class of the static type of the object used to make the call.
  41 This CFI scheme can be enabled on its own using ``-fsanitize=cfi-vcall``.
  42
  43 For this scheme to work, all translation units containing the definition
  44 of a virtual member function (whether inline or not), other than members
  45 of :ref:`blacklisted <cfi-blacklist>` types, must be compiled with
  46 ``-fsanitize=cfi-vcall`` enabled and be statically linked into the program.
  47
  48 Performance
  49 ~~~~~~~~~~~
  50
  51 A performance overhead of less than 1% has been measured by running the
  52 Dromaeo benchmark suite against an instrumented version of the Chromium
  53 web browser. Another good performance benchmark for this mechanism is the
  54 virtual-call-heavy SPEC 2006 xalancbmk.
  55
  56 Note that this scheme has not yet been optimized for binary size; an increase
  57 of up to 15% has been observed for Chromium.
  58
  59 Bad Cast Checking
  60 -----------------
  61
  62 This scheme checks that pointer casts are made to an object of the correct
  63 dynamic type; that is, the dynamic type of the object must be a derived class
  64 of the pointee type of the cast. The checks are currently only introduced
  65 where the class being casted to is a polymorphic class.
  66
  67 Bad casts are not in themselves control flow integrity violations, but they
  68 can also create security vulnerabilities, and the implementation uses many
  69 of the same mechanisms.
  70
  71 There are two types of bad cast that may be forbidden: bad casts
  72 from a base class to a derived class (which can be checked with
  73 ``-fsanitize=cfi-derived-cast``), and bad casts from a pointer of
  74 type ``void*`` or another unrelated type (which can be checked with
  75 ``-fsanitize=cfi-unrelated-cast``).
  76
  77 The difference between these two types of casts is that the first is defined
  78 by the C++ standard to produce an undefined value, while the second is not
  79 in itself undefined behavior (it is well defined to cast the pointer back
  80 to its original type).
  81
  82 If a program as a matter of policy forbids the second type of cast, that
  83 restriction can normally be enforced. However it may in some cases be necessary
  84 for a function to perform a forbidden cast to conform with an external API
  85 (e.g. the ``allocate`` member function of a standard library allocator). Such
  86 functions may be :ref:`blacklisted <cfi-blacklist>`.
  87
  88 For this scheme to work, all translation units containing the definition
  89 of a virtual member function (whether inline or not), other than members
  90 of :ref:`blacklisted <cfi-blacklist>` types, must be compiled with
  91 ``-fsanitize=cfi-derived-cast`` or ``-fsanitize=cfi-unrelated-cast`` enabled
  92 and be statically linked into the program.
  93
  94 Non-Virtual Member Function Call Checking
  95 -----------------------------------------
  96
  97 This scheme checks that non-virtual calls take place using an object of
  98 the correct dynamic type; that is, the dynamic type of the called object
  99 must be a derived class of the static type of the object used to make the
 100 call. The checks are currently only introduced where the object is of a
 101 polymorphic class type.  This CFI scheme can be enabled on its own using
 102 ``-fsanitize=cfi-nvcall``.
 103
 104 For this scheme to work, all translation units containing the definition
 105 of a virtual member function (whether inline or not), other than members
 106 of :ref:`blacklisted <cfi-blacklist>` types, must be compiled with
 107 ``-fsanitize=cfi-nvcall`` enabled and be statically linked into the program.
 108
 109 .. _cfi-strictness:
 110
 111 Strictness
 112 ~~~~~~~~~~
 113
 114 If a class has a single non-virtual base and does not introduce or override
 115 virtual member functions or fields other than an implicitly defined virtual
 116 destructor, it will have the same layout and virtual function semantics as
 117 its base. By default, casts to such classes are checked as if they were made
 118 to the least derived such class.
 119
 120 Casting an instance of a base class to such a derived class is technically
 121 undefined behavior, but it is a relatively common hack for introducing
 122 member functions on class instances with specific properties that works under
 123 most compilers and should not have security implications, so we allow it by
 124 default. It can be disabled with ``-fsanitize=cfi-cast-strict``.
 125
 126 .. _cfi-blacklist:
 127
 128 Blacklist
 129 ---------
 130
 131 A :doc:`SanitizerSpecialCaseList` can be used to relax CFI checks for certain
 132 source files, functions and types using the ``src``, ``fun`` and ``type``
 133 entity types.
 134
 135 In addition, if a type has a ``uuid`` attribute and the blacklist contains
 136 the type entry ``attr:uuid``, CFI checks are suppressed for that type. This
 137 allows all COM types to be easily blacklisted, which is useful as COM types
 138 are typically defined outside of the linked program.
 139
 140 .. code-block:: bash
 141
 142     # Suppress checking for code in a file.
 143     src:bad_file.cpp
 144     src:bad_header.h
 145     # Ignore all functions with names containing MyFooBar.
 146     fun:*MyFooBar*
 147     # Ignore all types in the standard library.
 148     type:std::*
 149     # Ignore all types with a uuid attribute.
 150     type:attr:uuid
 151
 152 Design
 153 ------
 154
 155 Please refer to the :doc:`design document<ControlFlowIntegrityDesign>`.
 156
 157 Publications
 158 ------------
 159
 160 `Control-Flow Integrity: Principles, Implementations, and Applications <http://research.microsoft.com/pubs/64250/ccs05.pdf>`_.
 161 Martin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti.
 162
 163 `Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM <http://www.pcc.me.uk/~peter/acad/usenix14.pdf>`_.
 164 Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway,
 165 Úlfar Erlingsson, Luis Lozano, Geoff Pike.