Stephen Hines | 0e2c34f | 2015-03-23 12:09:02 -0700 | [diff] [blame] | 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); the CFI |
| 24 | schemes imply ``-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 | |
Pirama Arumuga Nainar | 33337ca | 2015-05-06 11:48:57 -0700 | [diff] [blame] | 30 | Clang currently implements forward-edge CFI for member function calls and |
| 31 | bad cast checking. More schemes are under development. |
Stephen Hines | 0e2c34f | 2015-03-23 12:09:02 -0700 | [diff] [blame] | 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. |
Pirama Arumuga Nainar | 33337ca | 2015-05-06 11:48:57 -0700 | [diff] [blame] | 41 | This CFI scheme can be enabled on its own using ``-fsanitize=cfi-vcall``. |
Stephen Hines | 0e2c34f | 2015-03-23 12:09:02 -0700 | [diff] [blame] | 42 | |
| 43 | For this scheme to work, all translation units containing the definition |
| 44 | of a virtual member function (whether inline or not) must be compiled |
Pirama Arumuga Nainar | 33337ca | 2015-05-06 11:48:57 -0700 | [diff] [blame] | 45 | with ``-fsanitize=cfi-vcall`` enabled and be statically linked into the |
Stephen Hines | 0e2c34f | 2015-03-23 12:09:02 -0700 | [diff] [blame] | 46 | program. Classes in the C++ standard library (under namespace ``std``) are |
| 47 | exempted from checking, and therefore programs may be linked against a |
| 48 | pre-built standard library, but this may change in the future. |
| 49 | |
| 50 | Performance |
| 51 | ~~~~~~~~~~~ |
| 52 | |
| 53 | A performance overhead of less than 1% has been measured by running the |
| 54 | Dromaeo benchmark suite against an instrumented version of the Chromium |
| 55 | web browser. Another good performance benchmark for this mechanism is the |
| 56 | virtual-call-heavy SPEC 2006 xalancbmk. |
| 57 | |
| 58 | Note that this scheme has not yet been optimized for binary size; an increase |
| 59 | of up to 15% has been observed for Chromium. |
| 60 | |
Pirama Arumuga Nainar | 3ea9e33 | 2015-04-08 08:57:32 -0700 | [diff] [blame] | 61 | Bad Cast Checking |
| 62 | ----------------- |
| 63 | |
| 64 | This scheme checks that pointer casts are made to an object of the correct |
| 65 | dynamic type; that is, the dynamic type of the object must be a derived class |
| 66 | of the pointee type of the cast. The checks are currently only introduced |
| 67 | where the class being casted to is a polymorphic class. |
| 68 | |
| 69 | Bad casts are not in themselves control flow integrity violations, but they |
| 70 | can also create security vulnerabilities, and the implementation uses many |
| 71 | of the same mechanisms. |
| 72 | |
| 73 | There are two types of bad cast that may be forbidden: bad casts |
| 74 | from a base class to a derived class (which can be checked with |
| 75 | ``-fsanitize=cfi-derived-cast``), and bad casts from a pointer of |
| 76 | type ``void*`` or another unrelated type (which can be checked with |
| 77 | ``-fsanitize=cfi-unrelated-cast``). |
| 78 | |
| 79 | The difference between these two types of casts is that the first is defined |
| 80 | by the C++ standard to produce an undefined value, while the second is not |
| 81 | in itself undefined behavior (it is well defined to cast the pointer back |
| 82 | to its original type). |
| 83 | |
| 84 | If a program as a matter of policy forbids the second type of cast, that |
| 85 | restriction can normally be enforced. However it may in some cases be necessary |
| 86 | for a function to perform a forbidden cast to conform with an external API |
| 87 | (e.g. the ``allocate`` member function of a standard library allocator). Such |
| 88 | functions may be blacklisted using a :doc:`SanitizerSpecialCaseList`. |
| 89 | |
| 90 | For this scheme to work, all translation units containing the definition |
| 91 | of a virtual member function (whether inline or not) must be compiled with |
| 92 | ``-fsanitize=cfi-derived-cast`` or ``-fsanitize=cfi-unrelated-cast`` enabled |
| 93 | and be statically linked into the program. Classes in the C++ standard library |
| 94 | (under namespace ``std``) are exempted from checking, and therefore programs |
| 95 | may be linked against a pre-built standard library, but this may change in |
| 96 | the future. |
| 97 | |
Pirama Arumuga Nainar | 33337ca | 2015-05-06 11:48:57 -0700 | [diff] [blame] | 98 | Non-Virtual Member Function Call Checking |
| 99 | ----------------------------------------- |
| 100 | |
| 101 | This scheme checks that non-virtual calls take place using an object of |
| 102 | the correct dynamic type; that is, the dynamic type of the called object |
| 103 | must be a derived class of the static type of the object used to make the |
| 104 | call. The checks are currently only introduced where the object is of a |
| 105 | polymorphic class type. This CFI scheme can be enabled on its own using |
| 106 | ``-fsanitize=cfi-nvcall``. |
| 107 | |
| 108 | For this scheme to work, all translation units containing the definition |
| 109 | of a virtual member function (whether inline or not) must be compiled |
| 110 | with ``-fsanitize=cfi-nvcall`` enabled and be statically linked into the |
| 111 | program. Classes in the C++ standard library (under namespace ``std``) are |
| 112 | exempted from checking, and therefore programs may be linked against a |
| 113 | pre-built standard library, but this may change in the future. |
| 114 | |
Pirama Arumuga Nainar | 3ea9e33 | 2015-04-08 08:57:32 -0700 | [diff] [blame] | 115 | .. _cfi-strictness: |
| 116 | |
| 117 | Strictness |
| 118 | ~~~~~~~~~~ |
| 119 | |
| 120 | If a class has a single non-virtual base and does not introduce or override |
| 121 | virtual member functions or fields other than an implicitly defined virtual |
| 122 | destructor, it will have the same layout and virtual function semantics as |
| 123 | its base. By default, casts to such classes are checked as if they were made |
| 124 | to the least derived such class. |
| 125 | |
| 126 | Casting an instance of a base class to such a derived class is technically |
| 127 | undefined behavior, but it is a relatively common hack for introducing |
| 128 | member functions on class instances with specific properties that works under |
| 129 | most compilers and should not have security implications, so we allow it by |
| 130 | default. It can be disabled with ``-fsanitize=cfi-cast-strict``. |
| 131 | |
Stephen Hines | 0e2c34f | 2015-03-23 12:09:02 -0700 | [diff] [blame] | 132 | Design |
| 133 | ------ |
| 134 | |
| 135 | Please refer to the :doc:`design document<ControlFlowIntegrityDesign>`. |
| 136 | |
| 137 | Publications |
| 138 | ------------ |
| 139 | |
| 140 | `Control-Flow Integrity: Principles, Implementations, and Applications <http://research.microsoft.com/pubs/64250/ccs05.pdf>`_. |
| 141 | Martin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti. |
| 142 | |
| 143 | `Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM <http://www.pcc.me.uk/~peter/acad/usenix14.pdf>`_. |
| 144 | Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway, |
| 145 | Úlfar Erlingsson, Luis Lozano, Geoff Pike. |