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