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``. 23You can also enable a subset of available :ref:`schemes <cfi-schemes>`. 24As currently implemented, all schemes rely on link-time optimization (LTO); 25so it is required to specify ``-flto``, and the linker used must support LTO, 26for example via the `gold plugin`_. 27 28To allow the checks to be implemented efficiently, the program must 29be structured such that certain object files are compiled with CFI 30enabled, and are statically linked into the program. This may preclude 31the use of shared libraries in some cases. 32 33The compiler will only produce CFI checks for a class if it can infer hidden 34LTO visibility for that class. LTO visibility is a property of a class that 35is inferred from flags and attributes. For more details, see the documentation 36for :doc:`LTO visibility <LTOVisibility>`. 37 38The ``-fsanitize=cfi-{vcall,nvcall,derived-cast,unrelated-cast}`` flags 39require that a ``-fvisibility=`` flag also be specified. This is because the 40default visibility setting is ``-fvisibility=default``, which would disable 41CFI checks for classes without visibility attributes. Most users will want 42to specify ``-fvisibility=hidden``, which enables CFI checks for such classes. 43 44Experimental support for :ref:`cross-DSO control flow integrity 45<cfi-cross-dso>` exists that does not require classes to have hidden LTO 46visibility. This cross-DSO support has unstable ABI at this time. 47 48.. _gold plugin: https://llvm.org/docs/GoldPlugin.html 49 50.. _cfi-schemes: 51 52Available schemes 53================= 54 55Available schemes are: 56 57 - ``-fsanitize=cfi-cast-strict``: Enables :ref:`strict cast checks 58 <cfi-strictness>`. 59 - ``-fsanitize=cfi-derived-cast``: Base-to-derived cast to the wrong 60 dynamic type. 61 - ``-fsanitize=cfi-unrelated-cast``: Cast from ``void*`` or another 62 unrelated type to the wrong dynamic type. 63 - ``-fsanitize=cfi-nvcall``: Non-virtual call via an object whose vptr is of 64 the wrong dynamic type. 65 - ``-fsanitize=cfi-vcall``: Virtual call via an object whose vptr is of the 66 wrong dynamic type. 67 - ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic 68 type. 69 - ``-fsanitize=cfi-mfcall``: Indirect call via a member function pointer with 70 wrong dynamic type. 71 72You can use ``-fsanitize=cfi`` to enable all the schemes and use 73``-fno-sanitize`` flag to narrow down the set of schemes as desired. 74For example, you can build your program with 75``-fsanitize=cfi -fno-sanitize=cfi-nvcall,cfi-icall`` 76to use all schemes except for non-virtual member function call and indirect call 77checking. 78 79Remember that you have to provide ``-flto`` if at least one CFI scheme is 80enabled. 81 82Trapping and Diagnostics 83======================== 84 85By default, CFI will abort the program immediately upon detecting a control 86flow integrity violation. You can use the :ref:`-fno-sanitize-trap= 87<controlling-code-generation>` flag to cause CFI to print a diagnostic 88similar to the one below before the program aborts. 89 90.. code-block:: console 91 92 bad-cast.cpp:109:7: runtime error: control flow integrity check for type 'B' failed during base-to-derived cast (vtable address 0x000000425a50) 93 0x000000425a50: note: vtable is of type 'A' 94 00 00 00 00 f0 f1 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 5a 42 00 95 ^ 96 97If diagnostics are enabled, you can also configure CFI to continue program 98execution instead of aborting by using the :ref:`-fsanitize-recover= 99<controlling-code-generation>` flag. 100 101Forward-Edge CFI for Virtual Calls 102================================== 103 104This scheme checks that virtual calls take place using a vptr of the correct 105dynamic type; that is, the dynamic type of the called object must be a 106derived class of the static type of the object used to make the call. 107This CFI scheme can be enabled on its own using ``-fsanitize=cfi-vcall``. 108 109For this scheme to work, all translation units containing the definition 110of a virtual member function (whether inline or not), other than members 111of :ref:`blacklisted <cfi-blacklist>` types or types with public :doc:`LTO 112visibility <LTOVisibility>`, must be compiled with ``-flto`` or ``-flto=thin`` 113enabled and be statically linked into the program. 114 115Performance 116----------- 117 118A performance overhead of less than 1% has been measured by running the 119Dromaeo benchmark suite against an instrumented version of the Chromium 120web browser. Another good performance benchmark for this mechanism is the 121virtual-call-heavy SPEC 2006 xalancbmk. 122 123Note that this scheme has not yet been optimized for binary size; an increase 124of up to 15% has been observed for Chromium. 125 126Bad Cast Checking 127================= 128 129This scheme checks that pointer casts are made to an object of the correct 130dynamic type; that is, the dynamic type of the object must be a derived class 131of the pointee type of the cast. The checks are currently only introduced 132where the class being casted to is a polymorphic class. 133 134Bad casts are not in themselves control flow integrity violations, but they 135can also create security vulnerabilities, and the implementation uses many 136of the same mechanisms. 137 138There are two types of bad cast that may be forbidden: bad casts 139from a base class to a derived class (which can be checked with 140``-fsanitize=cfi-derived-cast``), and bad casts from a pointer of 141type ``void*`` or another unrelated type (which can be checked with 142``-fsanitize=cfi-unrelated-cast``). 143 144The difference between these two types of casts is that the first is defined 145by the C++ standard to produce an undefined value, while the second is not 146in itself undefined behavior (it is well defined to cast the pointer back 147to its original type) unless the object is uninitialized and the cast is a 148``static_cast`` (see C++14 [basic.life]p5). 149 150If a program as a matter of policy forbids the second type of cast, that 151restriction can normally be enforced. However it may in some cases be necessary 152for a function to perform a forbidden cast to conform with an external API 153(e.g. the ``allocate`` member function of a standard library allocator). Such 154functions may be :ref:`blacklisted <cfi-blacklist>`. 155 156For this scheme to work, all translation units containing the definition 157of a virtual member function (whether inline or not), other than members 158of :ref:`blacklisted <cfi-blacklist>` types or types with public :doc:`LTO 159visibility <LTOVisibility>`, must be compiled with ``-flto`` or ``-flto=thin`` 160enabled and be statically linked into the program. 161 162Non-Virtual Member Function Call Checking 163========================================= 164 165This scheme checks that non-virtual calls take place using an object of 166the correct dynamic type; that is, the dynamic type of the called object 167must be a derived class of the static type of the object used to make the 168call. The checks are currently only introduced where the object is of a 169polymorphic class type. This CFI scheme can be enabled on its own using 170``-fsanitize=cfi-nvcall``. 171 172For this scheme to work, all translation units containing the definition 173of a virtual member function (whether inline or not), other than members 174of :ref:`blacklisted <cfi-blacklist>` types or types with public :doc:`LTO 175visibility <LTOVisibility>`, must be compiled with ``-flto`` or ``-flto=thin`` 176enabled and be statically linked into the program. 177 178.. _cfi-strictness: 179 180Strictness 181---------- 182 183If a class has a single non-virtual base and does not introduce or override 184virtual member functions or fields other than an implicitly defined virtual 185destructor, it will have the same layout and virtual function semantics as 186its base. By default, casts to such classes are checked as if they were made 187to the least derived such class. 188 189Casting an instance of a base class to such a derived class is technically 190undefined behavior, but it is a relatively common hack for introducing 191member functions on class instances with specific properties that works under 192most compilers and should not have security implications, so we allow it by 193default. It can be disabled with ``-fsanitize=cfi-cast-strict``. 194 195Indirect Function Call Checking 196=============================== 197 198This scheme checks that function calls take place using a function of the 199correct dynamic type; that is, the dynamic type of the function must match 200the static type used at the call. This CFI scheme can be enabled on its own 201using ``-fsanitize=cfi-icall``. 202 203For this scheme to work, each indirect function call in the program, other 204than calls in :ref:`blacklisted <cfi-blacklist>` functions, must call a 205function which was either compiled with ``-fsanitize=cfi-icall`` enabled, 206or whose address was taken by a function in a translation unit compiled with 207``-fsanitize=cfi-icall``. 208 209If a function in a translation unit compiled with ``-fsanitize=cfi-icall`` 210takes the address of a function not compiled with ``-fsanitize=cfi-icall``, 211that address may differ from the address taken by a function in a translation 212unit not compiled with ``-fsanitize=cfi-icall``. This is technically a 213violation of the C and C++ standards, but it should not affect most programs. 214 215Each translation unit compiled with ``-fsanitize=cfi-icall`` must be 216statically linked into the program or shared library, and calls across 217shared library boundaries are handled as if the callee was not compiled with 218``-fsanitize=cfi-icall``. 219 220This scheme is currently only supported on the x86 and x86_64 architectures. 221 222``-fsanitize-cfi-icall-generalize-pointers`` 223-------------------------------------------- 224 225Mismatched pointer types are a common cause of cfi-icall check failures. 226Translation units compiled with the ``-fsanitize-cfi-icall-generalize-pointers`` 227flag relax pointer type checking for call sites in that translation unit, 228applied across all functions compiled with ``-fsanitize=cfi-icall``. 229 230Specifically, pointers in return and argument types are treated as equivalent as 231long as the qualifiers for the type they point to match. For example, ``char*``, 232``char**``, and ``int*`` are considered equivalent types. However, ``char*`` and 233``const char*`` are considered separate types. 234 235``-fsanitize-cfi-icall-generalize-pointers`` is not compatible with 236``-fsanitize-cfi-cross-dso``. 237 238 239``-fsanitize=cfi-icall`` and ``-fsanitize=function`` 240---------------------------------------------------- 241 242This tool is similar to ``-fsanitize=function`` in that both tools check 243the types of function calls. However, the two tools occupy different points 244on the design space; ``-fsanitize=function`` is a developer tool designed 245to find bugs in local development builds, whereas ``-fsanitize=cfi-icall`` 246is a security hardening mechanism designed to be deployed in release builds. 247 248``-fsanitize=function`` has a higher space and time overhead due to a more 249complex type check at indirect call sites, as well as a need for run-time 250type information (RTTI), which may make it unsuitable for deployment. Because 251of the need for RTTI, ``-fsanitize=function`` can only be used with C++ 252programs, whereas ``-fsanitize=cfi-icall`` can protect both C and C++ programs. 253 254On the other hand, ``-fsanitize=function`` conforms more closely with the C++ 255standard and user expectations around interaction with shared libraries; 256the identity of function pointers is maintained, and calls across shared 257library boundaries are no different from calls within a single program or 258shared library. 259 260Member Function Pointer Call Checking 261===================================== 262 263This scheme checks that indirect calls via a member function pointer 264take place using an object of the correct dynamic type. Specifically, we 265check that the dynamic type of the member function referenced by the member 266function pointer matches the "function pointer" part of the member function 267pointer, and that the member function's class type is related to the base 268type of the member function. This CFI scheme can be enabled on its own using 269``-fsanitize=cfi-mfcall``. 270 271The compiler will only emit a full CFI check if the member function pointer's 272base type is complete. This is because the complete definition of the base 273type contains information that is necessary to correctly compile the CFI 274check. To ensure that the compiler always emits a full CFI check, it is 275recommended to also pass the flag ``-fcomplete-member-pointers``, which 276enables a non-conforming language extension that requires member pointer 277base types to be complete if they may be used for a call. 278 279For this scheme to work, all translation units containing the definition 280of a virtual member function (whether inline or not), other than members 281of :ref:`blacklisted <cfi-blacklist>` types or types with public :doc:`LTO 282visibility <LTOVisibility>`, must be compiled with ``-flto`` or ``-flto=thin`` 283enabled and be statically linked into the program. 284 285This scheme is currently not compatible with cross-DSO CFI or the 286Microsoft ABI. 287 288.. _cfi-blacklist: 289 290Blacklist 291========= 292 293A :doc:`SanitizerSpecialCaseList` can be used to relax CFI checks for certain 294source files, functions and types using the ``src``, ``fun`` and ``type`` 295entity types. Specific CFI modes can be be specified using ``[section]`` 296headers. 297 298.. code-block:: bash 299 300 # Suppress all CFI checking for code in a file. 301 src:bad_file.cpp 302 src:bad_header.h 303 # Ignore all functions with names containing MyFooBar. 304 fun:*MyFooBar* 305 # Ignore all types in the standard library. 306 type:std::* 307 # Disable only unrelated cast checks for this function 308 [cfi-unrelated-cast] 309 fun:*UnrelatedCast* 310 # Disable CFI call checks for this function without affecting cast checks 311 [cfi-vcall|cfi-nvcall|cfi-icall] 312 fun:*BadCall* 313 314 315.. _cfi-cross-dso: 316 317Shared library support 318====================== 319 320Use **-f[no-]sanitize-cfi-cross-dso** to enable the cross-DSO control 321flow integrity mode, which allows all CFI schemes listed above to 322apply across DSO boundaries. As in the regular CFI, each DSO must be 323built with ``-flto``. 324 325Normally, CFI checks will only be performed for classes that have hidden LTO 326visibility. With this flag enabled, the compiler will emit cross-DSO CFI 327checks for all classes, except for those which appear in the CFI blacklist 328or which use a ``no_sanitize`` attribute. 329 330Design 331====== 332 333Please refer to the :doc:`design document<ControlFlowIntegrityDesign>`. 334 335Publications 336============ 337 338`Control-Flow Integrity: Principles, Implementations, and Applications <https://research.microsoft.com/pubs/64250/ccs05.pdf>`_. 339Martin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti. 340 341`Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM <http://www.pcc.me.uk/~peter/acad/usenix14.pdf>`_. 342Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway, 343Úlfar Erlingsson, Luis Lozano, Geoff Pike. 344