Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Implement Control Flow Integrity for virtual calls.
This patch introduces the -fsanitize=cfi-vptr flag, which enables a control flow integrity scheme that checks that virtual calls take place using a vptr of the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst file. It also introduces the -fsanitize=cfi flag, which is currently a synonym for -fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented in Clang. Differential Revision: http://reviews.llvm.org/D7424 llvm-svn: 230055
- Loading branch information
Showing
20 changed files
with
377 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,74 @@ | ||
====================== | ||
Control Flow Integrity | ||
====================== | ||
|
||
.. toctree:: | ||
:hidden: | ||
|
||
ControlFlowIntegrityDesign | ||
|
||
.. contents:: | ||
:local: | ||
|
||
Introduction | ||
============ | ||
|
||
Clang includes an implementation of a number of control flow integrity (CFI) | ||
schemes, which are designed to abort the program upon detecting certain forms | ||
of undefined behavior that can potentially allow attackers to subvert the | ||
program'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``. | ||
As currently implemented, CFI relies on link-time optimization (LTO); the CFI | ||
schemes imply ``-flto``, and the linker used must support LTO, for example | ||
via the `gold plugin`_. To allow the checks to be implemented efficiently, | ||
the program must be structured such that certain object files are compiled | ||
with CFI enabled, and are statically linked into the program. This may | ||
preclude the use of shared libraries in some cases. | ||
|
||
Clang currently implements forward-edge CFI for virtual calls. More schemes | ||
are under development. | ||
|
||
.. _gold plugin: http://llvm.org/docs/GoldPlugin.html | ||
|
||
Forward-Edge CFI for Virtual Calls | ||
---------------------------------- | ||
|
||
This scheme checks that virtual calls take place using a vptr of the correct | ||
dynamic type; that is, the dynamic type of the called object must be a | ||
derived 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-vptr``. | ||
|
||
For this scheme to work, all translation units containing the definition | ||
of a virtual member function (whether inline or not) must be compiled | ||
with ``-fsanitize=cfi-vptr`` enabled and be statically linked into the | ||
program. Classes in the C++ standard library (under namespace ``std``) are | ||
exempted from checking, and therefore programs may be linked against a | ||
pre-built standard library, but this may change in the future. | ||
|
||
Performance | ||
~~~~~~~~~~~ | ||
|
||
A performance overhead of less than 1% has been measured by running the | ||
Dromaeo benchmark suite against an instrumented version of the Chromium | ||
web browser. Another good performance benchmark for this mechanism is the | ||
virtual-call-heavy SPEC 2006 xalancbmk. | ||
|
||
Note that this scheme has not yet been optimized for binary size; an increase | ||
of up to 15% has been observed for Chromium. | ||
|
||
Design | ||
------ | ||
|
||
Please refer to the :doc:`design document<ControlFlowIntegrityDesign>`. | ||
|
||
Publications | ||
------------ | ||
|
||
`Control-Flow Integrity: Principles, Implementations, and Applications <http://research.microsoft.com/pubs/64250/ccs05.pdf>`_. | ||
Martin Abadi, Mihai Budiu, Úlfar Erlingsson, Jay Ligatti. | ||
|
||
`Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM <http://www.pcc.me.uk/~peter/acad/usenix14.pdf>`_. | ||
Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway, | ||
Úlfar Erlingsson, Luis Lozano, Geoff Pike. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,59 @@ | ||
=========================================== | ||
Control Flow Integrity Design Documentation | ||
=========================================== | ||
|
||
This page documents the design of the :doc:`ControlFlowIntegrity` schemes | ||
supported by Clang. | ||
|
||
Forward-Edge CFI for Virtual Calls | ||
---------------------------------- | ||
|
||
This scheme works by allocating, for each static type used to make a virtual | ||
call, a region of read-only storage in the object file holding a bit vector | ||
that maps onto to the region of storage used for those virtual tables. Each | ||
set bit in the bit vector corresponds to the `address point`_ for a virtual | ||
table compatible with the static type for which the bit vector is being built. | ||
|
||
For example, consider the following three C++ classes: | ||
|
||
.. code-block:: c++ | ||
|
||
struct A { | ||
virtual void f(); | ||
}; | ||
|
||
struct B : A { | ||
virtual void f(); | ||
}; | ||
|
||
struct C : A { | ||
virtual void f(); | ||
}; | ||
|
||
The scheme will cause the virtual tables for A, B and C to be laid out | ||
consecutively: | ||
|
||
.. csv-table:: Virtual Table Layout for A, B, C | ||
:header: 0, 1, 2, 3, 4, 5, 6, 7, 8 | ||
|
||
A::offset-to-top, &A::rtti, &A::f, B::offset-to-top, &B::rtti, &B::f, C::offset-to-top, &C::rtti, &C::f | ||
|
||
The bit vector for static types A, B and C will look like this: | ||
|
||
.. csv-table:: Bit Vectors for A, B, C | ||
:header: Class, 0, 1, 2, 3, 4, 5, 6, 7, 8 | ||
|
||
A, 0, 0, 1, 0, 0, 1, 0, 0, 1 | ||
B, 0, 0, 0, 0, 0, 1, 0, 0, 0 | ||
C, 0, 0, 0, 0, 0, 0, 0, 0, 1 | ||
|
||
To emit a virtual call, the compiler will assemble code that checks that | ||
the object's virtual table pointer is in-bounds and aligned and that the | ||
relevant bit is set in the bit vector. | ||
|
||
The compiler relies on co-operation from the linker in order to assemble | ||
the bit vector for the whole program. It currently does this using LLVM's | ||
`bit sets`_ mechanism together with link-time optimization. | ||
|
||
.. _address point: https://mentorembedded.github.io/cxx-abi/abi.html#vtable-general | ||
.. _bit sets: http://llvm.org/docs/BitSets.html |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.