diff options
Diffstat (limited to 'clang/docs')
| -rw-r--r-- | clang/docs/ControlFlowIntegrity.rst | 30 | ||||
| -rw-r--r-- | clang/docs/LTOVisibility.rst | 6 |
2 files changed, 33 insertions, 3 deletions
diff --git a/clang/docs/ControlFlowIntegrity.rst b/clang/docs/ControlFlowIntegrity.rst index 6b397befdd9..fcc64098889 100644 --- a/clang/docs/ControlFlowIntegrity.rst +++ b/clang/docs/ControlFlowIntegrity.rst @@ -66,6 +66,8 @@ Available schemes are: wrong dynamic type. - ``-fsanitize=cfi-icall``: Indirect call of a function with wrong dynamic type. + - ``-fsanitize=cfi-mfcall``: Indirect call via a member function pointer with + wrong 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. @@ -255,6 +257,34 @@ the identity of function pointers is maintained, and calls across shared library boundaries are no different from calls within a single program or shared library. +Member Function Pointer Call Checking +===================================== + +This scheme checks that indirect calls via a member function pointer +take place using an object of the correct dynamic type. Specifically, we +check that the dynamic type of the member function referenced by the member +function pointer matches the "function pointer" part of the member function +pointer, and that the member function's class type is related to the base +type 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's +base type is complete. This is because the complete definition of the base +type contains information that is necessary to correctly compile the CFI +check. To ensure that the compiler always emits a full CFI check, it is +recommended to also pass the flag ``-fcomplete-member-pointers``, which +enables a non-conforming language extension that requires member pointer +base types to be complete if they may be used for a call. + +For this scheme to work, all translation units containing the definition +of a virtual member function (whether inline or not), other than members +of :ref:`blacklisted <cfi-blacklist>` types or types with public :doc:`LTO +visibility <LTOVisibility>`, must be compiled with ``-flto`` or ``-flto=thin`` +enabled and be statically linked into the program. + +This scheme is currently not compatible with cross-DSO CFI or the +Microsoft ABI. + .. _cfi-blacklist: Blacklist diff --git a/clang/docs/LTOVisibility.rst b/clang/docs/LTOVisibility.rst index e1372d667a1..ed15d8d7867 100644 --- a/clang/docs/LTOVisibility.rst +++ b/clang/docs/LTOVisibility.rst @@ -11,9 +11,9 @@ linkage unit's LTO unit is empty. Each linkage unit has only a single LTO unit. The LTO visibility of a class is used by the compiler to determine which classes the whole-program devirtualization (``-fwhole-program-vtables``) and -control flow integrity (``-fsanitize=cfi-vcall``) features apply to. These -features use whole-program information, so they require the entire class -hierarchy to be visible in order to work correctly. +control flow integrity (``-fsanitize=cfi-vcall`` and ``-fsanitize=cfi-mfcall``) +features apply to. These features use whole-program information, so they +require the entire class hierarchy to be visible in order to work correctly. If any translation unit in the program uses either of the whole-program devirtualization or control flow integrity features, it is effectively an ODR |
