2c7f7e31c4
This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism. Differential Revision: http://reviews.llvm.org/D11857 llvm-svn: 247238
284 lines
11 KiB
ReStructuredText
284 lines
11 KiB
ReStructuredText
===========================================
|
|
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 f1();
|
|
virtual void f2();
|
|
virtual void f3();
|
|
};
|
|
|
|
struct B : A {
|
|
virtual void f1();
|
|
virtual void f2();
|
|
virtual void f3();
|
|
};
|
|
|
|
struct C : A {
|
|
virtual void f1();
|
|
virtual void f2();
|
|
virtual void f3();
|
|
};
|
|
|
|
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, 9, 10, 11, 12, 13, 14
|
|
|
|
A::offset-to-top, &A::rtti, &A::f1, &A::f2, &A::f3, B::offset-to-top, &B::rtti, &B::f1, &B::f2, &B::f3, C::offset-to-top, &C::rtti, &C::f1, &C::f2, &C::f3
|
|
|
|
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, 9, 10, 11, 12, 13, 14
|
|
|
|
A, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
|
|
B, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0
|
|
C, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0
|
|
|
|
Bit vectors are represented in the object file as byte arrays. By loading
|
|
from indexed offsets into the byte array and applying a mask, a program can
|
|
test bits from the bit set with a relatively short instruction sequence. Bit
|
|
vectors may overlap so long as they use different bits. For the full details,
|
|
see the `ByteArrayBuilder`_ class.
|
|
|
|
In this case, assuming A is laid out at offset 0 in bit 0, B at offset 0 in
|
|
bit 1 and C at offset 0 in bit 2, the byte array would look like this:
|
|
|
|
.. code-block:: c++
|
|
|
|
char bits[] = { 0, 0, 1, 0, 0, 0, 3, 0, 0, 0, 0, 5, 0, 0 };
|
|
|
|
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.
|
|
|
|
For example on x86 a typical virtual call may look like this:
|
|
|
|
.. code-block:: none
|
|
|
|
ca7fbb: 48 8b 0f mov (%rdi),%rcx
|
|
ca7fbe: 48 8d 15 c3 42 fb 07 lea 0x7fb42c3(%rip),%rdx
|
|
ca7fc5: 48 89 c8 mov %rcx,%rax
|
|
ca7fc8: 48 29 d0 sub %rdx,%rax
|
|
ca7fcb: 48 c1 c0 3d rol $0x3d,%rax
|
|
ca7fcf: 48 3d 7f 01 00 00 cmp $0x17f,%rax
|
|
ca7fd5: 0f 87 36 05 00 00 ja ca8511
|
|
ca7fdb: 48 8d 15 c0 0b f7 06 lea 0x6f70bc0(%rip),%rdx
|
|
ca7fe2: f6 04 10 10 testb $0x10,(%rax,%rdx,1)
|
|
ca7fe6: 0f 84 25 05 00 00 je ca8511
|
|
ca7fec: ff 91 98 00 00 00 callq *0x98(%rcx)
|
|
[...]
|
|
ca8511: 0f 0b ud2
|
|
|
|
The compiler relies on co-operation from the linker in order to assemble
|
|
the bit vectors 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
|
|
.. _ByteArrayBuilder: http://llvm.org/docs/doxygen/html/structllvm_1_1ByteArrayBuilder.html
|
|
|
|
Optimizations
|
|
-------------
|
|
|
|
The scheme as described above is the fully general variant of the scheme.
|
|
Most of the time we are able to apply one or more of the following
|
|
optimizations to improve binary size or performance.
|
|
|
|
In fact, if you try the above example with the current version of the
|
|
compiler, you will probably find that it will not use the described virtual
|
|
table layout or machine instructions. Some of the optimizations we are about
|
|
to introduce cause the compiler to use a different layout or a different
|
|
sequence of machine instructions.
|
|
|
|
Stripping Leading/Trailing Zeros in Bit Vectors
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If a bit vector contains leading or trailing zeros, we can strip them from
|
|
the vector. The compiler will emit code to check if the pointer is in range
|
|
of the region covered by ones, and perform the bit vector check using a
|
|
truncated version of the bit vector. For example, the bit vectors for our
|
|
example class hierarchy will be emitted like this:
|
|
|
|
.. csv-table:: Bit Vectors for A, B, C
|
|
:header: Class, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
|
|
|
|
A, , , 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, ,
|
|
B, , , , , , , , 1, , , , , , ,
|
|
C, , , , , , , , , , , , , 1, ,
|
|
|
|
Short Inline Bit Vectors
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If the vector is sufficiently short, we can represent it as an inline constant
|
|
on x86. This saves us a few instructions when reading the correct element
|
|
of the bit vector.
|
|
|
|
If the bit vector fits in 32 bits, the code looks like this:
|
|
|
|
.. code-block:: none
|
|
|
|
dc2: 48 8b 03 mov (%rbx),%rax
|
|
dc5: 48 8d 15 14 1e 00 00 lea 0x1e14(%rip),%rdx
|
|
dcc: 48 89 c1 mov %rax,%rcx
|
|
dcf: 48 29 d1 sub %rdx,%rcx
|
|
dd2: 48 c1 c1 3d rol $0x3d,%rcx
|
|
dd6: 48 83 f9 03 cmp $0x3,%rcx
|
|
dda: 77 2f ja e0b <main+0x9b>
|
|
ddc: ba 09 00 00 00 mov $0x9,%edx
|
|
de1: 0f a3 ca bt %ecx,%edx
|
|
de4: 73 25 jae e0b <main+0x9b>
|
|
de6: 48 89 df mov %rbx,%rdi
|
|
de9: ff 10 callq *(%rax)
|
|
[...]
|
|
e0b: 0f 0b ud2
|
|
|
|
Or if the bit vector fits in 64 bits:
|
|
|
|
.. code-block:: none
|
|
|
|
11a6: 48 8b 03 mov (%rbx),%rax
|
|
11a9: 48 8d 15 d0 28 00 00 lea 0x28d0(%rip),%rdx
|
|
11b0: 48 89 c1 mov %rax,%rcx
|
|
11b3: 48 29 d1 sub %rdx,%rcx
|
|
11b6: 48 c1 c1 3d rol $0x3d,%rcx
|
|
11ba: 48 83 f9 2a cmp $0x2a,%rcx
|
|
11be: 77 35 ja 11f5 <main+0xb5>
|
|
11c0: 48 ba 09 00 00 00 00 movabs $0x40000000009,%rdx
|
|
11c7: 04 00 00
|
|
11ca: 48 0f a3 ca bt %rcx,%rdx
|
|
11ce: 73 25 jae 11f5 <main+0xb5>
|
|
11d0: 48 89 df mov %rbx,%rdi
|
|
11d3: ff 10 callq *(%rax)
|
|
[...]
|
|
11f5: 0f 0b ud2
|
|
|
|
If the bit vector consists of a single bit, there is only one possible
|
|
virtual table, and the check can consist of a single equality comparison:
|
|
|
|
.. code-block:: none
|
|
|
|
9a2: 48 8b 03 mov (%rbx),%rax
|
|
9a5: 48 8d 0d a4 13 00 00 lea 0x13a4(%rip),%rcx
|
|
9ac: 48 39 c8 cmp %rcx,%rax
|
|
9af: 75 25 jne 9d6 <main+0x86>
|
|
9b1: 48 89 df mov %rbx,%rdi
|
|
9b4: ff 10 callq *(%rax)
|
|
[...]
|
|
9d6: 0f 0b ud2
|
|
|
|
Virtual Table Layout
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The compiler lays out classes of disjoint hierarchies in separate regions
|
|
of the object file. At worst, bit vectors in disjoint hierarchies only
|
|
need to cover their disjoint hierarchy. But the closer that classes in
|
|
sub-hierarchies are laid out to each other, the smaller the bit vectors for
|
|
those sub-hierarchies need to be (see "Stripping Leading/Trailing Zeros in Bit
|
|
Vectors" above). The `GlobalLayoutBuilder`_ class is responsible for laying
|
|
out the globals efficiently to minimize the sizes of the underlying bitsets.
|
|
|
|
.. _GlobalLayoutBuilder: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/IPO/LowerBitSets.h?view=markup
|
|
|
|
Alignment
|
|
~~~~~~~~~
|
|
|
|
If all gaps between address points in a particular bit vector are multiples
|
|
of powers of 2, the compiler can compress the bit vector by strengthening
|
|
the alignment requirements of the virtual table pointer. For example, given
|
|
this class hierarchy:
|
|
|
|
.. code-block:: c++
|
|
|
|
struct A {
|
|
virtual void f1();
|
|
virtual void f2();
|
|
};
|
|
|
|
struct B : A {
|
|
virtual void f1();
|
|
virtual void f2();
|
|
virtual void f3();
|
|
virtual void f4();
|
|
virtual void f5();
|
|
virtual void f6();
|
|
};
|
|
|
|
struct C : A {
|
|
virtual void f1();
|
|
virtual void f2();
|
|
};
|
|
|
|
The virtual tables will be laid out like this:
|
|
|
|
.. csv-table:: Virtual Table Layout for A, B, C
|
|
:header: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
|
|
|
|
A::offset-to-top, &A::rtti, &A::f1, &A::f2, B::offset-to-top, &B::rtti, &B::f1, &B::f2, &B::f3, &B::f4, &B::f5, &B::f6, C::offset-to-top, &C::rtti, &C::f1, &C::f2
|
|
|
|
Notice that each address point for A is separated by 4 words. This lets us
|
|
emit a compressed bit vector for A that looks like this:
|
|
|
|
.. csv-table::
|
|
:header: 2, 6, 10, 14
|
|
|
|
1, 1, 0, 1
|
|
|
|
At call sites, the compiler will strengthen the alignment requirements by
|
|
using a different rotate count. For example, on a 64-bit machine where the
|
|
address points are 4-word aligned (as in A from our example), the ``rol``
|
|
instruction may look like this:
|
|
|
|
.. code-block:: none
|
|
|
|
dd2: 48 c1 c1 3b rol $0x3b,%rcx
|
|
|
|
Padding to Powers of 2
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Of course, this alignment scheme works best if the address points are
|
|
in fact aligned correctly. To make this more likely to happen, we insert
|
|
padding between virtual tables that in many cases aligns address points to
|
|
a power of 2. Specifically, our padding aligns virtual tables to the next
|
|
highest power of 2 bytes; because address points for specific base classes
|
|
normally appear at fixed offsets within the virtual table, this normally
|
|
has the effect of aligning the address points as well.
|
|
|
|
This scheme introduces tradeoffs between decreased space overhead for
|
|
instructions and bit vectors and increased overhead in the form of padding. We
|
|
therefore limit the amount of padding so that we align to no more than 128
|
|
bytes. This number was found experimentally to provide a good tradeoff.
|
|
|
|
Eliminating Bit Vector Checks for All-Ones Bit Vectors
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If the bit vector is all ones, the bit vector check is redundant; we simply
|
|
need to check that the address is in range and well aligned. This is more
|
|
likely to occur if the virtual tables are padded.
|
|
|
|
Forward-Edge CFI for Indirect Function Calls
|
|
============================================
|
|
|
|
Sorry, no documentation yet, but see the comments at the top of
|
|
``LowerBitSets::buildBitSetsFromFunctions`` in `LowerBitSets.cpp`_.
|
|
|
|
.. _LowerBitSets.cpp: http://llvm.org/klaus/llvm/blob/master/lib/Transforms/IPO/LowerBitSets.cpp
|