Control Flow Integrity¶

Introduction ¶

Clang includes an implementation of a number of control flow integrity (CFI)schemes, which are designed to abort the program upon detecting certain formsof undefined behavior that can potentially allow attackers to subvert theprogram’s control flow. These schemes have been optimized for performance,allowing developers to enable them in release builds.

To enable Clang’s available CFI schemes, use the flag-fsanitize=cfi. You can also enable a subset of availableschemes. As currently implemented, all schemesexcept forkcfi rely on link-time optimization (LTO); so it isrequired to specify-flto or-flto=thin, and the linker usedmust support LTO, for example via thegold plugin.

To allow the checks to be implemented efficiently, the program mustbe structured such that certain object files are compiled with CFIenabled, and are statically linked into the program. This may precludethe use of shared libraries in some cases.

The compiler will only produce CFI checks for a class if it can infer hiddenLTO visibility for that class. LTO visibility is a property of a class thatis inferred from flags and attributes. For more details, see the documentationforLTO visibility.

The-fsanitize=cfi-{vcall,nvcall,derived-cast,unrelated-cast} flagsrequire that a-fvisibility= flag also be specified. This is because thedefault visibility setting is-fvisibility=default, which would disableCFI checks for classes without visibility attributes. Most users will wantto specify-fvisibility=hidden, which enables CFI checks for such classes.

When using-fsanitize=cfi* with-flto=thin, it is recommendedto reduce link times by passing-funique-source-file-names, providedthat your program is compatible with it.

Experimental support forcross-DSO control flow integrity exists that does not require classes to have hidden LTOvisibility. This cross-DSO support has unstable ABI at this time.

Available schemes ¶

Available schemes are:

-fsanitize=cfi-cast-strict: Enablesstrict cast checks.
-fsanitize=cfi-derived-cast: Base-to-derived cast to the wrongdynamic type.
-fsanitize=cfi-unrelated-cast: Cast fromvoid* or anotherunrelated type to the wrong dynamic type.
-fsanitize=cfi-nvcall: Non-virtual call via an object whose vptr is ofthe wrong dynamic type.
-fsanitize=cfi-vcall: Virtual call via an object whose vptr is of thewrong dynamic type.
-fsanitize=cfi-icall: Indirect call of a function with wrong dynamictype.
-fsanitize=cfi-mfcall: Indirect call via a member function pointer withwrong dynamic type.

You can use-fsanitize=cfi to enable all the schemes and use-fno-sanitize flag to narrow down the set of schemes as desired.For example, you can build your program with-fsanitize=cfi-fno-sanitize=cfi-nvcall,cfi-icallto use all schemes except for non-virtual member function call and indirect callchecking.

Remember that you have to provide-flto or-flto=thin if atleast one CFI scheme is enabled.

Trapping and Diagnostics ¶

By default, CFI will abort the program immediately upon detecting a controlflow integrity violation. You can use the-fno-sanitize-trap= flag to cause CFI to print a diagnosticsimilar to the one below before the program aborts.

bad-cast.cpp:109:7: runtime error: control flow integrity check for type 'B' failed during base-to-derived cast (vtable address 0x000000425a50)0x000000425a50: note: vtable is of type 'A' 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              ^

If diagnostics are enabled, you can also configure CFI to continue programexecution instead of aborting by using the-fsanitize-recover= flag.

Forward-Edge CFI for Virtual Calls ¶

This scheme checks that virtual calls take place using a vptr of the correctdynamic type; that is, the dynamic type of the called object must be aderived class of the static type of the object used to make the call.This CFI scheme can be enabled on its own using-fsanitize=cfi-vcall.

For this scheme to work, all translation units containing the definitionof a virtual member function (whether inline or not), other than membersofignored types or types with publicLTOvisibility, must be compiled with-flto or-flto=thinenabled and be statically linked into the program.

Performance ¶

A performance overhead of less than 1% has been measured by running theDromaeo benchmark suite against an instrumented version of the Chromiumweb browser. Another good performance benchmark for this mechanism is thevirtual-call-heavy SPEC 2006 xalancbmk.

Note that this scheme has not yet been optimized for binary size; an increaseof up to 15% has been observed for Chromium.

Bad Cast Checking ¶

This scheme checks that pointer casts are made to an object of the correctdynamic type; that is, the dynamic type of the object must be a derived classof the pointee type of the cast. The checks are currently only introducedwhere the class being casted to is a polymorphic class.

Bad casts are not in themselves control flow integrity violations, but theycan also create security vulnerabilities, and the implementation uses manyof the same mechanisms.

There are two types of bad cast that may be forbidden: bad castsfrom a base class to a derived class (which can be checked with-fsanitize=cfi-derived-cast), and bad casts from a pointer oftypevoid* or another unrelated type (which can be checked with-fsanitize=cfi-unrelated-cast).

The difference between these two types of casts is that the first is definedby the C++ standard to produce an undefined value, while the second is notin itself undefined behavior (it is well defined to cast the pointer backto its original type) unless the object is uninitialized and the cast is astatic_cast (see C++14 [basic.life]p5).

If a program as a matter of policy forbids the second type of cast, thatrestriction can normally be enforced. However it may in some cases be necessaryfor a function to perform a forbidden cast to conform with an external API(e.g. theallocate member function of a standard library allocator). Suchfunctions may beignored.

Non-Virtual Member Function Call Checking ¶

This scheme checks that non-virtual calls take place using an object ofthe correct dynamic type; that is, the dynamic type of the called objectmust be a derived class of the static type of the object used to make thecall. The checks are currently only introduced where the object is of apolymorphic class type. This CFI scheme can be enabled on its own using-fsanitize=cfi-nvcall.

Strictness ¶

If a class has a single non-virtual base and does not introduce or overridevirtual member functions or fields other than an implicitly defined virtualdestructor, it will have the same layout and virtual function semantics asits base. By default, casts to such classes are checked as if they were madeto the least derived such class.

Casting an instance of a base class to such a derived class is technicallyundefined behavior, but it is a relatively common hack for introducingmember functions on class instances with specific properties that works undermost compilers and should not have security implications, so we allow it bydefault. It can be disabled with-fsanitize=cfi-cast-strict.

Indirect Function Call Checking ¶

This scheme checks that function calls take place using a function of thecorrect dynamic type; that is, the dynamic type of the function must matchthe static type used at the call. This CFI scheme can be enabled on its ownusing-fsanitize=cfi-icall.

For this scheme to work, each indirect function call in the program, otherthan calls inignored functions, must call afunction which was either compiled with-fsanitize=cfi-icall enabled,or whose address was taken by a function in a translation unit compiled with-fsanitize=cfi-icall.

If a function in a translation unit compiled with-fsanitize=cfi-icalltakes the address of a function not compiled with-fsanitize=cfi-icall,that address may differ from the address taken by a function in a translationunit not compiled with-fsanitize=cfi-icall. This is technically aviolation of the C and C++ standards, but it should not affect most programs.

Each translation unit compiled with-fsanitize=cfi-icall must bestatically linked into the program or shared library, and calls acrossshared library boundaries are handled as if the callee was not compiled with-fsanitize=cfi-icall.

This scheme is currently supported on a limited set of targets: x86,x86_64, arm, arch64 and wasm.

`-fsanitize-cfi-icall-generalize-pointers`¶

Mismatched pointer types are a common cause of cfi-icall check failures.Translation units compiled with the-fsanitize-cfi-icall-generalize-pointersflag relax pointer type checking for call sites in that translation unit,applied across all functions compiled with-fsanitize=cfi-icall.

Specifically, pointers in return and argument types are treated as equivalent aslong as the qualifiers for the type they point to match. For example,char*,char**, andint* are considered equivalent types. However,char* andconstchar* are considered separate types.

-fsanitize-cfi-icall-generalize-pointers is not compatible with-fsanitize-cfi-cross-dso.

`-fsanitize-cfi-icall-experimental-normalize-integers`¶

This option enables normalizing integer types as vendor extended types forcross-language LLVM CFI/KCFI support with other languages that can’t representand encode C/C++ integer types.

Specifically, integer types are encoded as their defined representations (e.g.,8-bit signed integer, 16-bit signed integer, 32-bit signed integer, …) forcompatibility with languages that define explicitly-sized integer types (e.g.,i8, i16, i32, …, in Rust).

-fsanitize-cfi-icall-experimental-normalize-integers is compatible with-fsanitize-cfi-icall-generalize-pointers.

This option is currently experimental.

`-fsanitize-cfi-canonical-jump-tables`¶

The default behavior of Clang’s indirect function call checker will replacethe address of each CFI-checked function in the output file’s symbol tablewith the address of a jump table entry which will pass CFI checks. We referto this as making the jump tablecanonical. This property allows code thatwas not compiled with-fsanitize=cfi-icall to take a CFI-valid addressof a function, but it comes with a couple of caveats that are especiallyrelevant for users of cross-DSO CFI:

There is a performance and code size overhead associated with eachexported function, because each such function must have an associatedjump table entry, which must be emitted even in the common case where thefunction is never address-taken anywhere in the program, and must be usedeven for direct calls between DSOs, in addition to the PLT overhead.
There is no good way to take a CFI-valid address of a function written inassembly or a language not supported by Clang. The reason is that the codegenerator would need to insert a jump table in order to form a CFI-validaddress for assembly functions, but there is no way in general for thecode generator to determine the language of the function. This may bepossible with LTO in the intra-DSO case, but in the cross-DSO case the onlyinformation available is the function declaration. One possible solutionis to add a C wrapper for each assembly function, but these wrappers canpresent a significant maintenance burden for heavy users of assembly inaddition to adding runtime overhead.

For these reasons, we provide the option of making the jump table non-canonicalwith the flag-fno-sanitize-cfi-canonical-jump-tables. When the jumptable is made non-canonical, symbol table entries point directly to thefunction body. Any instances of a function’s address being taken in C willbe replaced with a jump table address.

This scheme does have its own caveats, however. It does end up breakingfunction address equality more aggressively than the default behavior,especially in cross-DSO mode which normally preserves function addressequality entirely.

Furthermore, it is occasionally necessary for code not compiled with-fsanitize=cfi-icall to take a function address that is validfor CFI. For example, this is necessary when a function’s addressis taken by assembly code and then called by CFI-checking C code. The__attribute__((cfi_canonical_jump_table)) attribute may be used to makethe jump table entry of a specific function canonical so that the externalcode will end up taking an address for the function that will pass CFI checks.

`-fsanitize=cfi-icall` and`-fsanitize=function`¶

This tool is similar to-fsanitize=function in that both tools checkthe types of function calls. However, the two tools occupy different pointson the design space;-fsanitize=function is a developer tool designedto find bugs in local development builds, whereas-fsanitize=cfi-icallis a security hardening mechanism designed to be deployed in release builds.

-fsanitize=function has a higher space and time overhead due to a morecomplex type check at indirect call sites, which may make it unsuitable fordeployment.

On the other hand,-fsanitize=function conforms more closely with the C++standard and user expectations around interaction with shared libraries;the identity of function pointers is maintained, and calls across sharedlibrary boundaries are no different from calls within a single program orshared library.

`-fsanitize=kcfi`¶

This is an alternative indirect call control-flow integrity scheme designedfor low-level system software, such as operating system kernels. Unlike-fsanitize=cfi-icall, it doesn’t require-flto, won’t result infunction pointers being replaced with jump table references, and never breakscross-DSO function address equality. These properties make KCFI easier toadopt in low-level software. KCFI is limited to checking only functionpointers, and isn’t compatible with executable-only memory.

`-fsanitize-kcfi-arity`¶

For supported targets, this feature extends kCFI by telling the compiler torecord information about each indirect-callable function’s arity (i.e., thenumber of arguments passed in registers) into the binary. Some kernel CFItechniques, such as FineIBT, may be able to use this information to provideenhanced security.

Member Function Pointer Call Checking ¶

This scheme checks that indirect calls via a member function pointertake place using an object of the correct dynamic type. Specifically, wecheck that the dynamic type of the member function referenced by the memberfunction pointer matches the “function pointer” part of the member functionpointer, and that the member function’s class type is related to the basetype of the member function. This CFI scheme can be enabled on its own using-fsanitize=cfi-mfcall.

The compiler will only emit a full CFI check if the member function pointer’sbase type is complete. This is because the complete definition of the basetype contains information that is necessary to correctly compile the CFIcheck. To ensure that the compiler always emits a full CFI check, it isrecommended to also pass the flag-fcomplete-member-pointers, whichenables a non-conforming language extension that requires member pointerbase types to be complete if they may be used for a call.

This scheme is currently not compatible with cross-DSO CFI or theMicrosoft ABI.

Ignorelist ¶

ASanitizer special case list can be used to relax CFI checks for certainsource files, functions and types using thesrc,fun andtypeentity types. Specific CFI modes can be be specified using[section]headers.

# Suppress all CFI checking for code in a file.src:bad_file.cppsrc:bad_header.h# Ignore all functions with names containing MyFooBar.fun:*MyFooBar*# Ignore all types in the standard library.type:std::*# Disable only unrelated cast checks for this function[cfi-unrelated-cast]fun:*UnrelatedCast*# Disable CFI call checks for this function without affecting cast checks[cfi-vcall|cfi-nvcall|cfi-icall]fun:*BadCall*

Shared library support ¶

Use-f[no-]sanitize-cfi-cross-dso to enable the cross-DSO controlflow integrity mode, which allows all CFI schemes listed above toapply across DSO boundaries. As in the regular CFI, each DSO must bebuilt with-flto or-flto=thin.

Normally, CFI checks will only be performed for classes that have hidden LTOvisibility. With this flag enabled, the compiler will emit cross-DSO CFIchecks for all classes, except for those which appear in the CFI ignorelistor which use ano_sanitize attribute.

Design ¶

Please refer to thedesign document.

Publications ¶

Control-Flow Integrity: Principles, Implementations, and Applications.Martin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti.

Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM.Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway,Úlfar Erlingsson, Luis Lozano, Geoff Pike.

Movatterモバイル変換

Clang 22.0.0git documentation