[www-releases] r342530 - 7.0.0 files
Hans Wennborg via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 19 02:40:15 PDT 2018
Added: www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrity.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrity.html?rev=342530&view=auto
==============================================================================
--- www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrity.html (added)
+++ www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrity.html Wed Sep 19 02:40:08 2018
@@ -0,0 +1,371 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Control Flow Integrity — Clang 7 documentation</title>
+ <link rel="stylesheet" href="_static/haiku.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: './',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true,
+ SOURCELINK_SUFFIX: '.txt'
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Control Flow Integrity Design Documentation" href="ControlFlowIntegrityDesign.html" />
+ <link rel="prev" title="Sanitizer special case list" href="SanitizerSpecialCaseList.html" />
+ </head>
+ <body>
+ <div class="header" role="banner"><h1 class="heading"><a href="index.html">
+ <span>Clang 7 documentation</span></a></h1>
+ <h2 class="heading"><span>Control Flow Integrity</span></h2>
+ </div>
+ <div class="topnav" role="navigation" aria-label="top navigation">
+
+ <p>
+ « <a href="SanitizerSpecialCaseList.html">Sanitizer special case list</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="ControlFlowIntegrityDesign.html">Control Flow Integrity Design Documentation</a> »
+ </p>
+
+ </div>
+ <div class="content">
+
+
+ <div class="section" id="control-flow-integrity">
+<h1>Control Flow Integrity<a class="headerlink" href="#control-flow-integrity" title="Permalink to this headline">¶</a></h1>
+<div class="toctree-wrapper compound">
+</div>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#available-schemes" id="id2">Available schemes</a></li>
+<li><a class="reference internal" href="#trapping-and-diagnostics" id="id3">Trapping and Diagnostics</a></li>
+<li><a class="reference internal" href="#forward-edge-cfi-for-virtual-calls" id="id4">Forward-Edge CFI for Virtual Calls</a><ul>
+<li><a class="reference internal" href="#performance" id="id5">Performance</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#bad-cast-checking" id="id6">Bad Cast Checking</a></li>
+<li><a class="reference internal" href="#non-virtual-member-function-call-checking" id="id7">Non-Virtual Member Function Call Checking</a><ul>
+<li><a class="reference internal" href="#strictness" id="id8">Strictness</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#indirect-function-call-checking" id="id9">Indirect Function Call Checking</a><ul>
+<li><a class="reference internal" href="#fsanitize-cfi-icall-generalize-pointers" id="id10"><code class="docutils literal"><span class="pre">-fsanitize-cfi-icall-generalize-pointers</span></code></a></li>
+<li><a class="reference internal" href="#fsanitize-cfi-icall-and-fsanitize-function" id="id11"><code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code> and <code class="docutils literal"><span class="pre">-fsanitize=function</span></code></a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#member-function-pointer-call-checking" id="id12">Member Function Pointer Call Checking</a></li>
+<li><a class="reference internal" href="#blacklist" id="id13">Blacklist</a></li>
+<li><a class="reference internal" href="#shared-library-support" id="id14">Shared library support</a></li>
+<li><a class="reference internal" href="#design" id="id15">Design</a></li>
+<li><a class="reference internal" href="#publications" id="id16">Publications</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>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.</p>
+<p>To enable Clangâs available CFI schemes, use the flag <code class="docutils literal"><span class="pre">-fsanitize=cfi</span></code>.
+You can also enable a subset of available <a class="reference internal" href="#cfi-schemes"><span class="std std-ref">schemes</span></a>.
+As currently implemented, all schemes rely on link-time optimization (LTO);
+so it is required to specify <code class="docutils literal"><span class="pre">-flto</span></code>, and the linker used must support LTO,
+for example via the <a class="reference external" href="http://llvm.org/docs/GoldPlugin.html">gold plugin</a>.</p>
+<p>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.</p>
+<p>The compiler will only produce CFI checks for a class if it can infer hidden
+LTO visibility for that class. LTO visibility is a property of a class that
+is inferred from flags and attributes. For more details, see the documentation
+for <a class="reference internal" href="LTOVisibility.html"><span class="doc">LTO visibility</span></a>.</p>
+<p>The <code class="docutils literal"><span class="pre">-fsanitize=cfi-{vcall,nvcall,derived-cast,unrelated-cast}</span></code> flags
+require that a <code class="docutils literal"><span class="pre">-fvisibility=</span></code> flag also be specified. This is because the
+default visibility setting is <code class="docutils literal"><span class="pre">-fvisibility=default</span></code>, which would disable
+CFI checks for classes without visibility attributes. Most users will want
+to specify <code class="docutils literal"><span class="pre">-fvisibility=hidden</span></code>, which enables CFI checks for such classes.</p>
+<p>Experimental support for <a class="reference internal" href="#cfi-cross-dso"><span class="std std-ref">cross-DSO control flow integrity</span></a> exists that does not require classes to have hidden LTO
+visibility. This cross-DSO support has unstable ABI at this time.</p>
+</div>
+<div class="section" id="available-schemes">
+<span id="cfi-schemes"></span><h2><a class="toc-backref" href="#id2">Available schemes</a><a class="headerlink" href="#available-schemes" title="Permalink to this headline">¶</a></h2>
+<p>Available schemes are:</p>
+<blockquote>
+<div><ul class="simple">
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-cast-strict</span></code>: Enables <a class="reference internal" href="#cfi-strictness"><span class="std std-ref">strict cast checks</span></a>.</li>
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-derived-cast</span></code>: Base-to-derived cast to the wrong
+dynamic type.</li>
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-unrelated-cast</span></code>: Cast from <code class="docutils literal"><span class="pre">void*</span></code> or another
+unrelated type to the wrong dynamic type.</li>
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-nvcall</span></code>: Non-virtual call via an object whose vptr is of
+the wrong dynamic type.</li>
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-vcall</span></code>: Virtual call via an object whose vptr is of the
+wrong dynamic type.</li>
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>: Indirect call of a function with wrong dynamic
+type.</li>
+<li><code class="docutils literal"><span class="pre">-fsanitize=cfi-mfcall</span></code>: Indirect call via a member function pointer with
+wrong dynamic type.</li>
+</ul>
+</div></blockquote>
+<p>You can use <code class="docutils literal"><span class="pre">-fsanitize=cfi</span></code> to enable all the schemes and use
+<code class="docutils literal"><span class="pre">-fno-sanitize</span></code> flag to narrow down the set of schemes as desired.
+For example, you can build your program with
+<code class="docutils literal"><span class="pre">-fsanitize=cfi</span> <span class="pre">-fno-sanitize=cfi-nvcall,cfi-icall</span></code>
+to use all schemes except for non-virtual member function call and indirect call
+checking.</p>
+<p>Remember that you have to provide <code class="docutils literal"><span class="pre">-flto</span></code> if at least one CFI scheme is
+enabled.</p>
+</div>
+<div class="section" id="trapping-and-diagnostics">
+<h2><a class="toc-backref" href="#id3">Trapping and Diagnostics</a><a class="headerlink" href="#trapping-and-diagnostics" title="Permalink to this headline">¶</a></h2>
+<p>By default, CFI will abort the program immediately upon detecting a control
+flow integrity violation. You can use the <a class="reference internal" href="UsersManual.html#controlling-code-generation"><span class="std std-ref">-fno-sanitize-trap=</span></a> flag to cause CFI to print a diagnostic
+similar to the one below before the program aborts.</p>
+<div class="highlight-console"><div class="highlight"><pre><span></span><span class="go">bad-cast.cpp:109:7: runtime error: control flow integrity check for type 'B' failed during base-to-derived cast (vtable address 0x000000425a50)</span>
+<span class="go">0x000000425a50: note: vtable is of type 'A'</span>
+<span class="go"> 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</span>
+<span class="go"> ^</span>
+</pre></div>
+</div>
+<p>If diagnostics are enabled, you can also configure CFI to continue program
+execution instead of aborting by using the <a class="reference internal" href="UsersManual.html#controlling-code-generation"><span class="std std-ref">-fsanitize-recover=</span></a> flag.</p>
+</div>
+<div class="section" id="forward-edge-cfi-for-virtual-calls">
+<h2><a class="toc-backref" href="#id4">Forward-Edge CFI for Virtual Calls</a><a class="headerlink" href="#forward-edge-cfi-for-virtual-calls" title="Permalink to this headline">¶</a></h2>
+<p>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 <code class="docutils literal"><span class="pre">-fsanitize=cfi-vcall</span></code>.</p>
+<p>For this scheme to work, all translation units containing the definition
+of a virtual member function (whether inline or not), other than members
+of <a class="reference internal" href="#cfi-blacklist"><span class="std std-ref">blacklisted</span></a> types or types with public <a class="reference internal" href="LTOVisibility.html"><span class="doc">LTO
+visibility</span></a>, must be compiled with <code class="docutils literal"><span class="pre">-flto</span></code> or <code class="docutils literal"><span class="pre">-flto=thin</span></code>
+enabled and be statically linked into the program.</p>
+<div class="section" id="performance">
+<h3><a class="toc-backref" href="#id5">Performance</a><a class="headerlink" href="#performance" title="Permalink to this headline">¶</a></h3>
+<p>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.</p>
+<p>Note that this scheme has not yet been optimized for binary size; an increase
+of up to 15% has been observed for Chromium.</p>
+</div>
+</div>
+<div class="section" id="bad-cast-checking">
+<h2><a class="toc-backref" href="#id6">Bad Cast Checking</a><a class="headerlink" href="#bad-cast-checking" title="Permalink to this headline">¶</a></h2>
+<p>This scheme checks that pointer casts are made to an object of the correct
+dynamic type; that is, the dynamic type of the object must be a derived class
+of the pointee type of the cast. The checks are currently only introduced
+where the class being casted to is a polymorphic class.</p>
+<p>Bad casts are not in themselves control flow integrity violations, but they
+can also create security vulnerabilities, and the implementation uses many
+of the same mechanisms.</p>
+<p>There are two types of bad cast that may be forbidden: bad casts
+from a base class to a derived class (which can be checked with
+<code class="docutils literal"><span class="pre">-fsanitize=cfi-derived-cast</span></code>), and bad casts from a pointer of
+type <code class="docutils literal"><span class="pre">void*</span></code> or another unrelated type (which can be checked with
+<code class="docutils literal"><span class="pre">-fsanitize=cfi-unrelated-cast</span></code>).</p>
+<p>The difference between these two types of casts is that the first is defined
+by the C++ standard to produce an undefined value, while the second is not
+in itself undefined behavior (it is well defined to cast the pointer back
+to its original type) unless the object is uninitialized and the cast is a
+<code class="docutils literal"><span class="pre">static_cast</span></code> (see C++14 [basic.life]p5).</p>
+<p>If a program as a matter of policy forbids the second type of cast, that
+restriction can normally be enforced. However it may in some cases be necessary
+for a function to perform a forbidden cast to conform with an external API
+(e.g. the <code class="docutils literal"><span class="pre">allocate</span></code> member function of a standard library allocator). Such
+functions may be <a class="reference internal" href="#cfi-blacklist"><span class="std std-ref">blacklisted</span></a>.</p>
+<p>For this scheme to work, all translation units containing the definition
+of a virtual member function (whether inline or not), other than members
+of <a class="reference internal" href="#cfi-blacklist"><span class="std std-ref">blacklisted</span></a> types or types with public <a class="reference internal" href="LTOVisibility.html"><span class="doc">LTO
+visibility</span></a>, must be compiled with <code class="docutils literal"><span class="pre">-flto</span></code> or <code class="docutils literal"><span class="pre">-flto=thin</span></code>
+enabled and be statically linked into the program.</p>
+</div>
+<div class="section" id="non-virtual-member-function-call-checking">
+<h2><a class="toc-backref" href="#id7">Non-Virtual Member Function Call Checking</a><a class="headerlink" href="#non-virtual-member-function-call-checking" title="Permalink to this headline">¶</a></h2>
+<p>This scheme checks that non-virtual calls take place using an object 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. The checks are currently only introduced where the object is of a
+polymorphic class type. This CFI scheme can be enabled on its own using
+<code class="docutils literal"><span class="pre">-fsanitize=cfi-nvcall</span></code>.</p>
+<p>For this scheme to work, all translation units containing the definition
+of a virtual member function (whether inline or not), other than members
+of <a class="reference internal" href="#cfi-blacklist"><span class="std std-ref">blacklisted</span></a> types or types with public <a class="reference internal" href="LTOVisibility.html"><span class="doc">LTO
+visibility</span></a>, must be compiled with <code class="docutils literal"><span class="pre">-flto</span></code> or <code class="docutils literal"><span class="pre">-flto=thin</span></code>
+enabled and be statically linked into the program.</p>
+<div class="section" id="strictness">
+<span id="cfi-strictness"></span><h3><a class="toc-backref" href="#id8">Strictness</a><a class="headerlink" href="#strictness" title="Permalink to this headline">¶</a></h3>
+<p>If a class has a single non-virtual base and does not introduce or override
+virtual member functions or fields other than an implicitly defined virtual
+destructor, it will have the same layout and virtual function semantics as
+its base. By default, casts to such classes are checked as if they were made
+to the least derived such class.</p>
+<p>Casting an instance of a base class to such a derived class is technically
+undefined behavior, but it is a relatively common hack for introducing
+member functions on class instances with specific properties that works under
+most compilers and should not have security implications, so we allow it by
+default. It can be disabled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-cast-strict</span></code>.</p>
+</div>
+</div>
+<div class="section" id="indirect-function-call-checking">
+<h2><a class="toc-backref" href="#id9">Indirect Function Call Checking</a><a class="headerlink" href="#indirect-function-call-checking" title="Permalink to this headline">¶</a></h2>
+<p>This scheme checks that function calls take place using a function of the
+correct dynamic type; that is, the dynamic type of the function must match
+the static type used at the call. This CFI scheme can be enabled on its own
+using <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>.</p>
+<p>For this scheme to work, each indirect function call in the program, other
+than calls in <a class="reference internal" href="#cfi-blacklist"><span class="std std-ref">blacklisted</span></a> functions, must call a
+function which was either compiled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code> enabled,
+or whose address was taken by a function in a translation unit compiled with
+<code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>.</p>
+<p>If a function in a translation unit compiled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>
+takes the address of a function not compiled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>,
+that address may differ from the address taken by a function in a translation
+unit not compiled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>. This is technically a
+violation of the C and C++ standards, but it should not affect most programs.</p>
+<p>Each translation unit compiled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code> must be
+statically linked into the program or shared library, and calls across
+shared library boundaries are handled as if the callee was not compiled with
+<code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>.</p>
+<p>This scheme is currently only supported on the x86 and x86_64 architectures.</p>
+<div class="section" id="fsanitize-cfi-icall-generalize-pointers">
+<h3><a class="toc-backref" href="#id10"><code class="docutils literal"><span class="pre">-fsanitize-cfi-icall-generalize-pointers</span></code></a><a class="headerlink" href="#fsanitize-cfi-icall-generalize-pointers" title="Permalink to this headline">¶</a></h3>
+<p>Mismatched pointer types are a common cause of cfi-icall check failures.
+Translation units compiled with the <code class="docutils literal"><span class="pre">-fsanitize-cfi-icall-generalize-pointers</span></code>
+flag relax pointer type checking for call sites in that translation unit,
+applied across all functions compiled with <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>.</p>
+<p>Specifically, pointers in return and argument types are treated as equivalent as
+long as the qualifiers for the type they point to match. For example, <code class="docutils literal"><span class="pre">char*</span></code>,
+<code class="docutils literal"><span class="pre">char**</span></code>, and <code class="docutils literal"><span class="pre">int*</span></code> are considered equivalent types. However, <code class="docutils literal"><span class="pre">char*</span></code> and
+<code class="docutils literal"><span class="pre">const</span> <span class="pre">char*</span></code> are considered separate types.</p>
+<p><code class="docutils literal"><span class="pre">-fsanitize-cfi-icall-generalize-pointers</span></code> is not compatible with
+<code class="docutils literal"><span class="pre">-fsanitize-cfi-cross-dso</span></code>.</p>
+</div>
+<div class="section" id="fsanitize-cfi-icall-and-fsanitize-function">
+<h3><a class="toc-backref" href="#id11"><code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code> and <code class="docutils literal"><span class="pre">-fsanitize=function</span></code></a><a class="headerlink" href="#fsanitize-cfi-icall-and-fsanitize-function" title="Permalink to this headline">¶</a></h3>
+<p>This tool is similar to <code class="docutils literal"><span class="pre">-fsanitize=function</span></code> in that both tools check
+the types of function calls. However, the two tools occupy different points
+on the design space; <code class="docutils literal"><span class="pre">-fsanitize=function</span></code> is a developer tool designed
+to find bugs in local development builds, whereas <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code>
+is a security hardening mechanism designed to be deployed in release builds.</p>
+<p><code class="docutils literal"><span class="pre">-fsanitize=function</span></code> has a higher space and time overhead due to a more
+complex type check at indirect call sites, as well as a need for run-time
+type information (RTTI), which may make it unsuitable for deployment. Because
+of the need for RTTI, <code class="docutils literal"><span class="pre">-fsanitize=function</span></code> can only be used with C++
+programs, whereas <code class="docutils literal"><span class="pre">-fsanitize=cfi-icall</span></code> can protect both C and C++ programs.</p>
+<p>On the other hand, <code class="docutils literal"><span class="pre">-fsanitize=function</span></code> 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 shared
+library boundaries are no different from calls within a single program or
+shared library.</p>
+</div>
+</div>
+<div class="section" id="member-function-pointer-call-checking">
+<h2><a class="toc-backref" href="#id12">Member Function Pointer Call Checking</a><a class="headerlink" href="#member-function-pointer-call-checking" title="Permalink to this headline">¶</a></h2>
+<p>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
+<code class="docutils literal"><span class="pre">-fsanitize=cfi-mfcall</span></code>.</p>
+<p>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 <code class="docutils literal"><span class="pre">-fcomplete-member-pointers</span></code>, which
+enables a non-conforming language extension that requires member pointer
+base types to be complete if they may be used for a call.</p>
+<p>For this scheme to work, all translation units containing the definition
+of a virtual member function (whether inline or not), other than members
+of <a class="reference internal" href="#cfi-blacklist"><span class="std std-ref">blacklisted</span></a> types or types with public <a class="reference internal" href="LTOVisibility.html"><span class="doc">LTO
+visibility</span></a>, must be compiled with <code class="docutils literal"><span class="pre">-flto</span></code> or <code class="docutils literal"><span class="pre">-flto=thin</span></code>
+enabled and be statically linked into the program.</p>
+<p>This scheme is currently not compatible with cross-DSO CFI or the
+Microsoft ABI.</p>
+</div>
+<div class="section" id="blacklist">
+<span id="cfi-blacklist"></span><h2><a class="toc-backref" href="#id13">Blacklist</a><a class="headerlink" href="#blacklist" title="Permalink to this headline">¶</a></h2>
+<p>A <a class="reference internal" href="SanitizerSpecialCaseList.html"><span class="doc">Sanitizer special case list</span></a> can be used to relax CFI checks for certain
+source files, functions and types using the <code class="docutils literal"><span class="pre">src</span></code>, <code class="docutils literal"><span class="pre">fun</span></code> and <code class="docutils literal"><span class="pre">type</span></code>
+entity types. Specific CFI modes can be be specified using <code class="docutils literal"><span class="pre">[section]</span></code>
+headers.</p>
+<div class="highlight-bash"><div class="highlight"><pre><span></span><span class="c1"># Suppress all CFI checking for code in a file.</span>
+src:bad_file.cpp
+src:bad_header.h
+<span class="c1"># Ignore all functions with names containing MyFooBar.</span>
+fun:*MyFooBar*
+<span class="c1"># Ignore all types in the standard library.</span>
+type:std::*
+<span class="c1"># Disable only unrelated cast checks for this function</span>
+<span class="o">[</span>cfi-unrelated-cast<span class="o">]</span>
+fun:*UnrelatedCast*
+<span class="c1"># Disable CFI call checks for this function without affecting cast checks</span>
+<span class="o">[</span>cfi-vcall<span class="p">|</span>cfi-nvcall<span class="p">|</span>cfi-icall<span class="o">]</span>
+fun:*BadCall*
+</pre></div>
+</div>
+</div>
+<div class="section" id="shared-library-support">
+<span id="cfi-cross-dso"></span><h2><a class="toc-backref" href="#id14">Shared library support</a><a class="headerlink" href="#shared-library-support" title="Permalink to this headline">¶</a></h2>
+<p>Use <strong>-f[no-]sanitize-cfi-cross-dso</strong> to enable the cross-DSO control
+flow integrity mode, which allows all CFI schemes listed above to
+apply across DSO boundaries. As in the regular CFI, each DSO must be
+built with <code class="docutils literal"><span class="pre">-flto</span></code>.</p>
+<p>Normally, CFI checks will only be performed for classes that have hidden LTO
+visibility. With this flag enabled, the compiler will emit cross-DSO CFI
+checks for all classes, except for those which appear in the CFI blacklist
+or which use a <code class="docutils literal"><span class="pre">no_sanitize</span></code> attribute.</p>
+</div>
+<div class="section" id="design">
+<h2><a class="toc-backref" href="#id15">Design</a><a class="headerlink" href="#design" title="Permalink to this headline">¶</a></h2>
+<p>Please refer to the <a class="reference internal" href="ControlFlowIntegrityDesign.html"><span class="doc">design document</span></a>.</p>
+</div>
+<div class="section" id="publications">
+<h2><a class="toc-backref" href="#id16">Publications</a><a class="headerlink" href="#publications" title="Permalink to this headline">¶</a></h2>
+<p><a class="reference external" href="http://research.microsoft.com/pubs/64250/ccs05.pdf">Control-Flow Integrity: Principles, Implementations, and Applications</a>.
+Martin Abadi, Mihai Budiu, Ãlfar Erlingsson, Jay Ligatti.</p>
+<p><a class="reference external" href="http://www.pcc.me.uk/~peter/acad/usenix14.pdf">Enforcing Forward-Edge Control-Flow Integrity in GCC & LLVM</a>.
+Caroline Tice, Tom Roeder, Peter Collingbourne, Stephen Checkoway,
+Ãlfar Erlingsson, Luis Lozano, Geoff Pike.</p>
+</div>
+</div>
+
+
+ </div>
+ <div class="bottomnav" role="navigation" aria-label="bottom navigation">
+
+ <p>
+ « <a href="SanitizerSpecialCaseList.html">Sanitizer special case list</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="ControlFlowIntegrityDesign.html">Control Flow Integrity Design Documentation</a> »
+ </p>
+
+ </div>
+
+ <div class="footer" role="contentinfo">
+ © Copyright 2007-2018, The Clang Team.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrityDesign.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrityDesign.html?rev=342530&view=auto
==============================================================================
--- www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrityDesign.html (added)
+++ www-releases/trunk/7.0.0/tools/clang/docs/ControlFlowIntegrityDesign.html Wed Sep 19 02:40:08 2018
@@ -0,0 +1,952 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Control Flow Integrity Design Documentation — Clang 7 documentation</title>
+ <link rel="stylesheet" href="_static/haiku.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: './',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true,
+ SOURCELINK_SUFFIX: '.txt'
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="LTO Visibility" href="LTOVisibility.html" />
+ <link rel="prev" title="Control Flow Integrity" href="ControlFlowIntegrity.html" />
+ </head>
+ <body>
+ <div class="header" role="banner"><h1 class="heading"><a href="index.html">
+ <span>Clang 7 documentation</span></a></h1>
+ <h2 class="heading"><span>Control Flow Integrity Design Documentation</span></h2>
+ </div>
+ <div class="topnav" role="navigation" aria-label="top navigation">
+
+ <p>
+ « <a href="ControlFlowIntegrity.html">Control Flow Integrity</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="LTOVisibility.html">LTO Visibility</a> »
+ </p>
+
+ </div>
+ <div class="content">
+
+
+ <div class="section" id="control-flow-integrity-design-documentation">
+<h1>Control Flow Integrity Design Documentation<a class="headerlink" href="#control-flow-integrity-design-documentation" title="Permalink to this headline">¶</a></h1>
+<p>This page documents the design of the <a class="reference internal" href="ControlFlowIntegrity.html"><span class="doc">Control Flow Integrity</span></a> schemes
+supported by Clang.</p>
+<div class="section" id="forward-edge-cfi-for-virtual-calls">
+<h2>Forward-Edge CFI for Virtual Calls<a class="headerlink" href="#forward-edge-cfi-for-virtual-calls" title="Permalink to this headline">¶</a></h2>
+<p>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 <a class="reference external" href="http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-general">address point</a> for a virtual
+table compatible with the static type for which the bit vector is being built.</p>
+<p>For example, consider the following three C++ classes:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f1</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f2</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f3</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="nl">B</span> <span class="p">:</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f1</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f2</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f3</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="nl">C</span> <span class="p">:</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f1</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f2</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f3</span><span class="p">();</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The scheme will cause the virtual tables for A, B and C to be laid out
+consecutively:</p>
+<table border="1" class="docutils" id="id1">
+<caption><span class="caption-text">Virtual Table Layout for A, B, C</span><a class="headerlink" href="#id1" title="Permalink to this table">¶</a></caption>
+<colgroup>
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+<col width="7%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">0</th>
+<th class="head">1</th>
+<th class="head">2</th>
+<th class="head">3</th>
+<th class="head">4</th>
+<th class="head">5</th>
+<th class="head">6</th>
+<th class="head">7</th>
+<th class="head">8</th>
+<th class="head">9</th>
+<th class="head">10</th>
+<th class="head">11</th>
+<th class="head">12</th>
+<th class="head">13</th>
+<th class="head">14</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>A::offset-to-top</td>
+<td>&A::rtti</td>
+<td>&A::f1</td>
+<td>&A::f2</td>
+<td>&A::f3</td>
+<td>B::offset-to-top</td>
+<td>&B::rtti</td>
+<td>&B::f1</td>
+<td>&B::f2</td>
+<td>&B::f3</td>
+<td>C::offset-to-top</td>
+<td>&C::rtti</td>
+<td>&C::f1</td>
+<td>&C::f2</td>
+<td>&C::f3</td>
+</tr>
+</tbody>
+</table>
+<p>The bit vector for static types A, B and C will look like this:</p>
+<table border="1" class="docutils" id="id2">
+<caption><span class="caption-text">Bit Vectors for A, B, C</span><a class="headerlink" href="#id2" title="Permalink to this table">¶</a></caption>
+<colgroup>
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Class</th>
+<th class="head">0</th>
+<th class="head">1</th>
+<th class="head">2</th>
+<th class="head">3</th>
+<th class="head">4</th>
+<th class="head">5</th>
+<th class="head">6</th>
+<th class="head">7</th>
+<th class="head">8</th>
+<th class="head">9</th>
+<th class="head">10</th>
+<th class="head">11</th>
+<th class="head">12</th>
+<th class="head">13</th>
+<th class="head">14</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>A</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+</tr>
+<tr class="row-odd"><td>B</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+</tr>
+<tr class="row-even"><td>C</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+</tr>
+</tbody>
+</table>
+<p>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 <a class="reference external" href="http://llvm.org/docs/doxygen/html/structllvm_1_1ByteArrayBuilder.html">ByteArrayBuilder</a> class.</p>
+<p>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:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span></span><span class="kt">char</span> <span class="n">bits</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">3</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">5</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="mi">0</span> <span class="p">};</span>
+</pre></div>
+</div>
+<p>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.</p>
+<p>For example on x86 a typical virtual call may look like this:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>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
+</pre></div>
+</div>
+<p>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
+<a class="reference external" href="http://llvm.org/docs/TypeMetadata.html">type metadata</a> mechanism together with link-time optimization.</p>
+<div class="section" id="optimizations">
+<h3>Optimizations<a class="headerlink" href="#optimizations" title="Permalink to this headline">¶</a></h3>
+<p>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.</p>
+<p>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.</p>
+<div class="section" id="stripping-leading-trailing-zeros-in-bit-vectors">
+<h4>Stripping Leading/Trailing Zeros in Bit Vectors<a class="headerlink" href="#stripping-leading-trailing-zeros-in-bit-vectors" title="Permalink to this headline">¶</a></h4>
+<p>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:</p>
+<table border="1" class="docutils" id="id3">
+<caption><span class="caption-text">Bit Vectors for A, B, C</span><a class="headerlink" href="#id3" title="Permalink to this table">¶</a></caption>
+<colgroup>
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Class</th>
+<th class="head">0</th>
+<th class="head">1</th>
+<th class="head">2</th>
+<th class="head">3</th>
+<th class="head">4</th>
+<th class="head">5</th>
+<th class="head">6</th>
+<th class="head">7</th>
+<th class="head">8</th>
+<th class="head">9</th>
+<th class="head">10</th>
+<th class="head">11</th>
+<th class="head">12</th>
+<th class="head">13</th>
+<th class="head">14</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>A</td>
+<td> </td>
+<td> </td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>0</td>
+<td>1</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr class="row-odd"><td>B</td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td>1</td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+</tr>
+<tr class="row-even"><td>C</td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td> </td>
+<td>1</td>
+<td> </td>
+<td> </td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="section" id="short-inline-bit-vectors">
+<h4>Short Inline Bit Vectors<a class="headerlink" href="#short-inline-bit-vectors" title="Permalink to this headline">¶</a></h4>
+<p>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.</p>
+<p>If the bit vector fits in 32 bits, the code looks like this:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span> 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
+</pre></div>
+</div>
+<p>Or if the bit vector fits in 64 bits:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>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
+</pre></div>
+</div>
+<p>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:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>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
+</pre></div>
+</div>
+</div>
+<div class="section" id="virtual-table-layout">
+<h4>Virtual Table Layout<a class="headerlink" href="#virtual-table-layout" title="Permalink to this headline">¶</a></h4>
+<p>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 <a class="reference external" href="http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Transforms/IPO/LowerTypeTests.h?view=markup">GlobalLayoutBuilder</a> class is responsible for laying
+out the globals efficiently to minimize the sizes of the underlying bitsets.</p>
+</div>
+<div class="section" id="alignment">
+<h4>Alignment<a class="headerlink" href="#alignment" title="Permalink to this headline">¶</a></h4>
+<p>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:</p>
+<div class="highlight-c++"><div class="highlight"><pre><span></span><span class="k">struct</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f1</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f2</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="nl">B</span> <span class="p">:</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f1</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f2</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f3</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f4</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f5</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f6</span><span class="p">();</span>
+<span class="p">};</span>
+
+<span class="k">struct</span> <span class="nl">C</span> <span class="p">:</span> <span class="n">A</span> <span class="p">{</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="n">f1</span><span class="p">();</span>
+ <span class="k">virtual</span> <span class="kt">void</span> <span class="nf">f2</span><span class="p">();</span>
+<span class="p">};</span>
+</pre></div>
+</div>
+<p>The virtual tables will be laid out like this:</p>
+<table border="1" class="docutils" id="id4">
+<caption><span class="caption-text">Virtual Table Layout for A, B, C</span><a class="headerlink" href="#id4" title="Permalink to this table">¶</a></caption>
+<colgroup>
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+<col width="6%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">0</th>
+<th class="head">1</th>
+<th class="head">2</th>
+<th class="head">3</th>
+<th class="head">4</th>
+<th class="head">5</th>
+<th class="head">6</th>
+<th class="head">7</th>
+<th class="head">8</th>
+<th class="head">9</th>
+<th class="head">10</th>
+<th class="head">11</th>
+<th class="head">12</th>
+<th class="head">13</th>
+<th class="head">14</th>
+<th class="head">15</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>A::offset-to-top</td>
+<td>&A::rtti</td>
+<td>&A::f1</td>
+<td>&A::f2</td>
+<td>B::offset-to-top</td>
+<td>&B::rtti</td>
+<td>&B::f1</td>
+<td>&B::f2</td>
+<td>&B::f3</td>
+<td>&B::f4</td>
+<td>&B::f5</td>
+<td>&B::f6</td>
+<td>C::offset-to-top</td>
+<td>&C::rtti</td>
+<td>&C::f1</td>
+<td>&C::f2</td>
+</tr>
+</tbody>
+</table>
+<p>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:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="25%" />
+<col width="25%" />
+<col width="25%" />
+<col width="25%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">2</th>
+<th class="head">6</th>
+<th class="head">10</th>
+<th class="head">14</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>1</td>
+<td>1</td>
+<td>0</td>
+<td>1</td>
+</tr>
+</tbody>
+</table>
+<p>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 <code class="docutils literal"><span class="pre">rol</span></code>
+instruction may look like this:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>dd2: 48 c1 c1 3b rol $0x3b,%rcx
+</pre></div>
+</div>
+</div>
+<div class="section" id="padding-to-powers-of-2">
+<h4>Padding to Powers of 2<a class="headerlink" href="#padding-to-powers-of-2" title="Permalink to this headline">¶</a></h4>
+<p>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.</p>
+<p>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.</p>
+</div>
+<div class="section" id="eliminating-bit-vector-checks-for-all-ones-bit-vectors">
+<h4>Eliminating Bit Vector Checks for All-Ones Bit Vectors<a class="headerlink" href="#eliminating-bit-vector-checks-for-all-ones-bit-vectors" title="Permalink to this headline">¶</a></h4>
+<p>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.</p>
+</div>
+</div>
+</div>
+<div class="section" id="forward-edge-cfi-for-indirect-function-calls">
+<h2>Forward-Edge CFI for Indirect Function Calls<a class="headerlink" href="#forward-edge-cfi-for-indirect-function-calls" title="Permalink to this headline">¶</a></h2>
+<p>Under forward-edge CFI for indirect function calls, each unique function
+type has its own bit vector, and at each call site we need to check that the
+function pointer is a member of the function typeâs bit vector. This scheme
+works in a similar way to forward-edge CFI for virtual calls, the distinction
+being that we need to build bit vectors of function entry points rather than
+of virtual tables.</p>
+<p>Unlike when re-arranging global variables, we cannot re-arrange functions
+in a particular order and base our calculations on the layout of the
+functionsâ entry points, as we have no idea how large a particular function
+will end up being (the function sizes could even depend on how we arrange
+the functions). Instead, we build a jump table, which is a block of code
+consisting of one branch instruction for each of the functions in the bit
+set that branches to the target function, and redirect any taken function
+addresses to the corresponding jump table entry. In this way, the distance
+between function entry points is predictable and controllable. In the object
+fileâs symbol table, the symbols for the target functions also refer to the
+jump table entries, so that addresses taken outside the module will pass
+any verification done inside the module.</p>
+<p>In more concrete terms, suppose we have three functions <code class="docutils literal"><span class="pre">f</span></code>, <code class="docutils literal"><span class="pre">g</span></code>,
+<code class="docutils literal"><span class="pre">h</span></code> which are all of the same type, and a function foo that returns their
+addresses:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>f:
+mov 0, %eax
+ret
+
+g:
+mov 1, %eax
+ret
+
+h:
+mov 2, %eax
+ret
+
+foo:
+mov f, %eax
+mov g, %edx
+mov h, %ecx
+ret
+</pre></div>
+</div>
+<p>Our jump table will (conceptually) look like this:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>f:
+jmp .Ltmp0 ; 5 bytes
+int3 ; 1 byte
+int3 ; 1 byte
+int3 ; 1 byte
+
+g:
+jmp .Ltmp1 ; 5 bytes
+int3 ; 1 byte
+int3 ; 1 byte
+int3 ; 1 byte
+
+h:
+jmp .Ltmp2 ; 5 bytes
+int3 ; 1 byte
+int3 ; 1 byte
+int3 ; 1 byte
+
+.Ltmp0:
+mov 0, %eax
+ret
+
+.Ltmp1:
+mov 1, %eax
+ret
+
+.Ltmp2:
+mov 2, %eax
+ret
+
+foo:
+mov f, %eax
+mov g, %edx
+mov h, %ecx
+ret
+</pre></div>
+</div>
+<p>Because the addresses of <code class="docutils literal"><span class="pre">f</span></code>, <code class="docutils literal"><span class="pre">g</span></code>, <code class="docutils literal"><span class="pre">h</span></code> are evenly spaced at a power of
+2, and function types do not overlap (unlike class types with base classes),
+we can normally apply the <a class="reference internal" href="#alignment">Alignment</a> and <a class="reference internal" href="#eliminating-bit-vector-checks-for-all-ones-bit-vectors">Eliminating Bit Vector Checks
+for All-Ones Bit Vectors</a> optimizations thus simplifying the check at each
+call site to a range and alignment check.</p>
+</div>
+<div class="section" id="shared-library-support">
+<h2>Shared library support<a class="headerlink" href="#shared-library-support" title="Permalink to this headline">¶</a></h2>
+<p><strong>EXPERIMENTAL</strong></p>
+<p>The basic CFI mode described above assumes that the application is a
+monolithic binary; at least that all possible virtual/indirect call
+targets and the entire class hierarchy are known at link time. The
+cross-DSO mode, enabled with <strong>-f[no-]sanitize-cfi-cross-dso</strong> relaxes
+this requirement by allowing virtual and indirect calls to cross the
+DSO boundary.</p>
+<p>Assuming the following setup: the binary consists of several
+instrumented and several uninstrumented DSOs. Some of them may be
+dlopen-ed/dlclose-d periodically, even frequently.</p>
+<blockquote>
+<div><ul class="simple">
+<li>Calls made from uninstrumented DSOs are not checked and just work.</li>
+<li>Calls inside any instrumented DSO are fully protected.</li>
+<li><dl class="first docutils">
+<dt>Calls between different instrumented DSOs are also protected, with</dt>
+<dd>a performance penalty (in addition to the monolithic CFI
+overhead).</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>Calls from an instrumented DSO to an uninstrumented one are</dt>
+<dd>unchecked and just work, with performance penalty.</dd>
+</dl>
+</li>
+<li><dl class="first docutils">
+<dt>Calls from an instrumented DSO outside of any known DSO are</dt>
+<dd>detected as CFI violations.</dd>
+</dl>
+</li>
+</ul>
+</div></blockquote>
+<p>In the monolithic scheme a call site is instrumented as</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>if (!InlinedFastCheck(f))
+ abort();
+call *f
+</pre></div>
+</div>
+<p>In the cross-DSO scheme it becomes</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>if (!InlinedFastCheck(f))
+ __cfi_slowpath(CallSiteTypeId, f);
+call *f
+</pre></div>
+</div>
+<div class="section" id="callsitetypeid">
+<h3>CallSiteTypeId<a class="headerlink" href="#callsitetypeid" title="Permalink to this headline">¶</a></h3>
+<p><code class="docutils literal"><span class="pre">CallSiteTypeId</span></code> is a stable process-wide identifier of the
+call-site type. For a virtual call site, the type in question is the class
+type; for an indirect function call it is the function signature. The
+mapping from a type to an identifier is an ABI detail. In the current,
+experimental, implementation the identifier of type T is calculated as
+follows:</p>
+<blockquote>
+<div><ul class="simple">
+<li>Obtain the mangled name for âtypeinfo name for Tâ.</li>
+<li>Calculate MD5 hash of the name as a string.</li>
+<li>Reinterpret the first 8 bytes of the hash as a little-endian
+64-bit integer.</li>
+</ul>
+</div></blockquote>
+<p>It is possible, but unlikely, that collisions in the
+<code class="docutils literal"><span class="pre">CallSiteTypeId</span></code> hashing will result in weaker CFI checks that would
+still be conservatively correct.</p>
+</div>
+<div class="section" id="cfi-check">
+<h3>CFI_Check<a class="headerlink" href="#cfi-check" title="Permalink to this headline">¶</a></h3>
+<p>In the general case, only the target DSO knows whether the call to
+function <code class="docutils literal"><span class="pre">f</span></code> with type <code class="docutils literal"><span class="pre">CallSiteTypeId</span></code> is valid or not. To
+export this information, every DSO implements</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>void __cfi_check(uint64 CallSiteTypeId, void *TargetAddr, void *DiagData)
+</pre></div>
+</div>
+<p>This function provides external modules with access to CFI checks for
+the targets inside this DSO. For each known <code class="docutils literal"><span class="pre">CallSiteTypeId</span></code>, this
+function performs an <code class="docutils literal"><span class="pre">llvm.type.test</span></code> with the corresponding type
+identifier. It reports an error if the type is unknown, or if the
+check fails. Depending on the values of compiler flags
+<code class="docutils literal"><span class="pre">-fsanitize-trap</span></code> and <code class="docutils literal"><span class="pre">-fsanitize-recover</span></code>, this function may
+print an error, abort and/or return to the caller. <code class="docutils literal"><span class="pre">DiagData</span></code> is an
+opaque pointer to the diagnostic information about the error, or
+<code class="docutils literal"><span class="pre">null</span></code> if the caller does not provide this information.</p>
+<p>The basic implementation is a large switch statement over all values
+of CallSiteTypeId supported by this DSO, and each case is similar to
+the InlinedFastCheck() in the basic CFI mode.</p>
+</div>
+<div class="section" id="cfi-shadow">
+<h3>CFI Shadow<a class="headerlink" href="#cfi-shadow" title="Permalink to this headline">¶</a></h3>
+<p>To route CFI checks to the target DSOâs __cfi_check function, a
+mapping from possible virtual / indirect call targets to the
+corresponding __cfi_check functions is maintained. This mapping is
+implemented as a sparse array of 2 bytes for every possible page (4096
+bytes) of memory. The table is kept readonly most of the time.</p>
+<p>There are 3 types of shadow values:</p>
+<blockquote>
+<div><ul class="simple">
+<li>Address in a CFI-instrumented DSO.</li>
+<li>Unchecked address (a âtrustedâ non-instrumented DSO). Encoded as
+value 0xFFFF.</li>
+<li>Invalid address (everything else). Encoded as value 0.</li>
+</ul>
+</div></blockquote>
+<p>For a CFI-instrumented DSO, a shadow value encodes the address of the
+__cfi_check function for all call targets in the corresponding memory
+page. If Addr is the target address, and V is the shadow value, then
+the address of __cfi_check is calculated as</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>__cfi_check = AlignUpTo(Addr, 4096) - (V + 1) * 4096
+</pre></div>
+</div>
+<p>This works as long as __cfi_check is aligned by 4096 bytes and located
+below any call targets in its DSO, but not more than 256MB apart from
+them.</p>
+</div>
+<div class="section" id="cfi-slowpath">
+<h3>CFI_SlowPath<a class="headerlink" href="#cfi-slowpath" title="Permalink to this headline">¶</a></h3>
+<p>The slow path check is implemented in a runtime support library as</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>void __cfi_slowpath(uint64 CallSiteTypeId, void *TargetAddr)
+void __cfi_slowpath_diag(uint64 CallSiteTypeId, void *TargetAddr, void *DiagData)
+</pre></div>
+</div>
+<p>These functions loads a shadow value for <code class="docutils literal"><span class="pre">TargetAddr</span></code>, finds the
+address of <code class="docutils literal"><span class="pre">__cfi_check</span></code> as described above and calls
+that. <code class="docutils literal"><span class="pre">DiagData</span></code> is an opaque pointer to diagnostic data which is
+passed verbatim to <code class="docutils literal"><span class="pre">__cfi_check</span></code>, and <code class="docutils literal"><span class="pre">__cfi_slowpath</span></code> passes
+<code class="docutils literal"><span class="pre">nullptr</span></code> instead.</p>
+<p>Compiler-RT library contains reference implementations of slowpath
+functions, but they have unresolvable issues with correctness and
+performance in the handling of dlopen(). It is recommended that
+platforms provide their own implementations, usually as part of libc
+or libdl.</p>
+</div>
+<div class="section" id="position-independent-executable-requirement">
+<h3>Position-independent executable requirement<a class="headerlink" href="#position-independent-executable-requirement" title="Permalink to this headline">¶</a></h3>
+<p>Cross-DSO CFI mode requires that the main executable is built as PIE.
+In non-PIE executables the address of an external function (taken from
+the main executable) is the address of that functionâs PLT record in
+the main executable. This would break the CFI checks.</p>
+</div>
+</div>
+<div class="section" id="backward-edge-cfi-for-return-statements-rcfi">
+<h2>Backward-edge CFI for return statements (RCFI)<a class="headerlink" href="#backward-edge-cfi-for-return-statements-rcfi" title="Permalink to this headline">¶</a></h2>
+<p>This section is a proposal. As of March 2017 it is not implemented.</p>
+<p>Backward-edge control flow (<cite>RET</cite> instructions) can be hijacked
+via overwriting the return address (<cite>RA</cite>) on stack.
+Various mitigation techniques (e.g. <a class="reference external" href="https://clang.llvm.org/docs/SafeStack.html">SafeStack</a>, <a class="reference external" href="http://xlab.tencent.com/en/2016/11/02/return-flow-guard">RFG</a>, <a class="reference external" href="https://software.intel.com/en-us/blogs/2016/06/09/intel-release-new-technology-specifications-protect-rop-attacks">Intel CET</a>)
+try to detect or prevent <cite>RA</cite> corruption on stack.</p>
+<p>RCFI enforces the expected control flow in several different ways described below.
+RCFI heavily relies on LTO.</p>
+<div class="section" id="leaf-functions">
+<h3>Leaf Functions<a class="headerlink" href="#leaf-functions" title="Permalink to this headline">¶</a></h3>
+<p>If <cite>f()</cite> is a leaf function (i.e. it has no calls
+except maybe no-return calls) it can be called using a special calling convention
+that stores <cite>RA</cite> in a dedicated register <cite>R</cite> before the <cite>CALL</cite> instruction.
+<cite>f()</cite> does not spill <cite>R</cite> and does not use the <cite>RET</cite> instruction,
+instead it uses the value in <cite>R</cite> to <cite>JMP</cite> to <cite>RA</cite>.</p>
+<p>This flavour of CFI is <em>precise</em>, i.e. the function is guaranteed to return
+to the point exactly following the call.</p>
+<p>An alternative approach is to
+copy <cite>RA</cite> from stack to <cite>R</cite> in the first instruction of <cite>f()</cite>,
+then <cite>JMP</cite> to <cite>R</cite>.
+This approach is simpler to implement (does not require changing the caller)
+but weaker (there is a small window when <cite>RA</cite> is actually stored on stack).</p>
+</div>
+<div class="section" id="functions-called-once">
+<h3>Functions called once<a class="headerlink" href="#functions-called-once" title="Permalink to this headline">¶</a></h3>
+<p>Suppose <cite>f()</cite> is called in just one place in the program
+(assuming we can verify this in LTO mode).
+In this case we can replace the <cite>RET</cite> instruction with a <cite>JMP</cite> instruction
+with the immediate constant for <cite>RA</cite>.
+This will <em>precisely</em> enforce the return control flow no matter what is stored on stack.</p>
+<p>Another variant is to compare <cite>RA</cite> on stack with the known constant and abort
+if they donât match; then <cite>JMP</cite> to the known constant address.</p>
+</div>
+<div class="section" id="functions-called-in-a-small-number-of-call-sites">
+<h3>Functions called in a small number of call sites<a class="headerlink" href="#functions-called-in-a-small-number-of-call-sites" title="Permalink to this headline">¶</a></h3>
+<p>We may extend the above approach to cases where <cite>f()</cite>
+is called more than once (but still a small number of times).
+With LTO we know all possible values of <cite>RA</cite> and we check them
+one-by-one (or using binary search) against the value on stack.
+If the match is found, we <cite>JMP</cite> to the known constant address, otherwise abort.</p>
+<p>This protection is <em>near-precise</em>, i.e. it guarantees that the control flow will
+be transferred to one of the valid return addresses for this function,
+but not necessary to the point of the most recent <cite>CALL</cite>.</p>
+</div>
+<div class="section" id="general-case">
+<h3>General case<a class="headerlink" href="#general-case" title="Permalink to this headline">¶</a></h3>
+<p>For functions called multiple times a <em>return jump table</em> is constructed
+in the same manner as jump tables for indirect function calls (see above).
+The correct jump table entry (or itâs index) is passed by <cite>CALL</cite> to <cite>f()</cite>
+(as an extra argument) and then spilled to stack.
+The <cite>RET</cite> instruction is replaced with a load of the jump table entry,
+jump table range check, and <cite>JMP</cite> to the jump table entry.</p>
+<p>This protection is also <em>near-precise</em>.</p>
+</div>
+<div class="section" id="returns-from-functions-called-indirectly">
+<h3>Returns from functions called indirectly<a class="headerlink" href="#returns-from-functions-called-indirectly" title="Permalink to this headline">¶</a></h3>
+<p>If a function is called indirectly, the return jump table is constructed for the
+equivalence class of functions instead of a single function.</p>
+</div>
+<div class="section" id="cross-dso-calls">
+<h3>Cross-DSO calls<a class="headerlink" href="#cross-dso-calls" title="Permalink to this headline">¶</a></h3>
+<p>Consider two instrumented DSOs, <cite>A</cite> and <cite>B</cite>. <cite>A</cite> defines <cite>f()</cite> and <cite>B</cite> calls it.</p>
+<p>This case will be handled similarly to the cross-DSO scheme using the slow path callback.</p>
+</div>
+<div class="section" id="non-goals">
+<h3>Non-goals<a class="headerlink" href="#non-goals" title="Permalink to this headline">¶</a></h3>
+<dl class="docutils">
+<dt>RCFI does not protect <cite>RET</cite> instructions:</dt>
+<dd><ul class="first last simple">
+<li>in non-instrumented DSOs,</li>
+<li>in instrumented DSOs for functions that are called from non-instrumented DSOs,</li>
+<li>embedded into other instructions (e.g. <cite>0f4fc3 cmovg %ebx,%eax</cite>).</li>
+</ul>
+</dd>
+</dl>
+</div>
+</div>
+<div class="section" id="hardware-support">
+<h2>Hardware support<a class="headerlink" href="#hardware-support" title="Permalink to this headline">¶</a></h2>
+<p>We believe that the above design can be efficiently implemented in hardware.
+A single new instruction added to an ISA would allow to perform the forward-edge CFI check
+with fewer bytes per check (smaller code size overhead) and potentially more
+efficiently. The current software-only instrumentation requires at least
+32-bytes per check (on x86_64).
+A hardware instruction may probably be less than ~ 12 bytes.
+Such instruction would check that the argument pointer is in-bounds,
+and is properly aligned, and if the checks fail it will either trap (in monolithic scheme)
+or call the slow path function (cross-DSO scheme).
+The bit vector lookup is probably too complex for a hardware implementation.</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span>// This instruction checks that 'Ptr'
+// * is aligned by (1 << kAlignment) and
+// * is inside [kRangeBeg, kRangeBeg+(kRangeSize<<kAlignment))
+// and if the check fails it jumps to the given target (slow path).
+//
+// 'Ptr' is a register, pointing to the virtual function table
+// or to the function which we need to check. We may require an explicit
+// fixed register to be used.
+// 'kAlignment' is a 4-bit constant.
+// 'kRangeSize' is a ~20-bit constant.
+// 'kRangeBeg' is a PC-relative constant (~28 bits)
+// pointing to the beginning of the allowed range for 'Ptr'.
+// 'kFailedCheckTarget': is a PC-relative constant (~28 bits)
+// representing the target to branch to when the check fails.
+// If kFailedCheckTarget==0, the process will trap
+// (monolithic binary scheme).
+// Otherwise it will jump to a handler that implements `CFI_SlowPath`
+// (cross-DSO scheme).
+CFI_Check(Ptr, kAlignment, kRangeSize, kRangeBeg, kFailedCheckTarget) {
+ if (Ptr < kRangeBeg ||
+ Ptr >= kRangeBeg + (kRangeSize << kAlignment) ||
+ Ptr & ((1 << kAlignment) - 1))
+ Jump(kFailedCheckTarget);
+}
+</pre></div>
+</div>
+<p>An alternative and more compact encoding would not use <cite>kFailedCheckTarget</cite>,
+and will trap on check failure instead.
+This will allow us to fit the instruction into <strong>8-9 bytes</strong>.
+The cross-DSO checks will be performed by a trap handler and
+performance-critical ones will have to be black-listed and checked using the
+software-only scheme.</p>
+<p>Note that such hardware extension would be complementary to checks
+at the callee side, such as e.g. <strong>Intel ENDBRANCH</strong>.
+Moreover, CFI would have two benefits over ENDBRANCH: a) precision and b)
+ability to protect against invalid casts between polymorphic types.</p>
+</div>
+</div>
+
+
+ </div>
+ <div class="bottomnav" role="navigation" aria-label="bottom navigation">
+
+ <p>
+ « <a href="ControlFlowIntegrity.html">Control Flow Integrity</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="LTOVisibility.html">LTO Visibility</a> »
+ </p>
+
+ </div>
+
+ <div class="footer" role="contentinfo">
+ © Copyright 2007-2018, The Clang Team.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.0/tools/clang/docs/CrossCompilation.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.0/tools/clang/docs/CrossCompilation.html?rev=342530&view=auto
==============================================================================
--- www-releases/trunk/7.0.0/tools/clang/docs/CrossCompilation.html (added)
+++ www-releases/trunk/7.0.0/tools/clang/docs/CrossCompilation.html Wed Sep 19 02:40:08 2018
@@ -0,0 +1,258 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>Cross-compilation using Clang — Clang 7 documentation</title>
+ <link rel="stylesheet" href="_static/haiku.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: './',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true,
+ SOURCELINK_SUFFIX: '.txt'
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="Thread Safety Analysis" href="ThreadSafetyAnalysis.html" />
+ <link rel="prev" title="Diagnostic flags in Clang" href="DiagnosticsReference.html" />
+ </head>
+ <body>
+ <div class="header" role="banner"><h1 class="heading"><a href="index.html">
+ <span>Clang 7 documentation</span></a></h1>
+ <h2 class="heading"><span>Cross-compilation using Clang</span></h2>
+ </div>
+ <div class="topnav" role="navigation" aria-label="top navigation">
+
+ <p>
+ « <a href="DiagnosticsReference.html">Diagnostic flags in Clang</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="ThreadSafetyAnalysis.html">Thread Safety Analysis</a> »
+ </p>
+
+ </div>
+ <div class="content">
+
+
+ <div class="section" id="cross-compilation-using-clang">
+<h1>Cross-compilation using Clang<a class="headerlink" href="#cross-compilation-using-clang" title="Permalink to this headline">¶</a></h1>
+<div class="section" id="introduction">
+<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>This document will guide you in choosing the right Clang options
+for cross-compiling your code to a different architecture. It assumes you
+already know how to compile the code in question for the host architecture,
+and that you know how to choose additional include and library paths.</p>
+<p>However, this document is <em>not</em> a âhow toâ and wonât help you setting your
+build system or Makefiles, nor choosing the right CMake options, etc.
+Also, it does not cover all the possible options, nor does it contain
+specific examples for specific architectures. For a concrete example, the
+<a class="reference external" href="http://llvm.org/docs/HowToCrossCompileLLVM.html">instructions for cross-compiling LLVM itself</a> may be of interest.</p>
+<p>After reading this document, you should be familiar with the main issues
+related to cross-compilation, and what main compiler options Clang provides
+for performing cross-compilation.</p>
+</div>
+<div class="section" id="cross-compilation-issues">
+<h2>Cross compilation issues<a class="headerlink" href="#cross-compilation-issues" title="Permalink to this headline">¶</a></h2>
+<p>In GCC world, every host/target combination has its own set of binaries,
+headers, libraries, etc. So, itâs usually simple to download a package
+with all files in, unzip to a directory and point the build system to
+that compiler, that will know about its location and find all it needs to
+when compiling your code.</p>
+<p>On the other hand, Clang/LLVM is natively a cross-compiler, meaning that
+one set of programs can compile to all targets by setting the <code class="docutils literal"><span class="pre">-target</span></code>
+option. That makes it a lot easier for programmers wishing to compile to
+different platforms and architectures, and for compiler developers that
+only have to maintain one build system, and for OS distributions, that
+need only one set of main packages.</p>
+<p>But, as is true to any cross-compiler, and given the complexity of
+different architectures, OSâs and options, itâs not always easy finding
+the headers, libraries or binutils to generate target specific code.
+So youâll need special options to help Clang understand what target
+youâre compiling to, where your tools are, etc.</p>
+<p>Another problem is that compilers come with standard libraries only (like
+<code class="docutils literal"><span class="pre">compiler-rt</span></code>, <code class="docutils literal"><span class="pre">libcxx</span></code>, <code class="docutils literal"><span class="pre">libgcc</span></code>, <code class="docutils literal"><span class="pre">libm</span></code>, etc), so youâll have to
+find and make available to the build system, every other library required
+to build your software, that is specific to your target. Itâs not enough to
+have your hostâs libraries installed.</p>
+<p>Finally, not all toolchains are the same, and consequently, not every Clang
+option will work magically. Some options, like <code class="docutils literal"><span class="pre">--sysroot</span></code> (which
+effectively changes the logical root for headers and libraries), assume
+all your binaries and libraries are in the same directory, which may not
+true when your cross-compiler was installed by the distributionâs package
+management. So, for each specific case, you may use more than one
+option, and in most cases, youâll end up setting include paths (<code class="docutils literal"><span class="pre">-I</span></code>) and
+library paths (<code class="docutils literal"><span class="pre">-L</span></code>) manually.</p>
+<dl class="docutils">
+<dt>To sum up, different toolchains can:</dt>
+<dd><ul class="first last simple">
+<li>be host/target specific or more flexible</li>
+<li>be in a single directory, or spread out across your system</li>
+<li>have different sets of libraries and headers by default</li>
+<li>need special options, which your build system wonât be able to figure
+out by itself</li>
+</ul>
+</dd>
+</dl>
+</div>
+<div class="section" id="general-cross-compilation-options-in-clang">
+<h2>General Cross-Compilation Options in Clang<a class="headerlink" href="#general-cross-compilation-options-in-clang" title="Permalink to this headline">¶</a></h2>
+<div class="section" id="target-triple">
+<h3>Target Triple<a class="headerlink" href="#target-triple" title="Permalink to this headline">¶</a></h3>
+<p>The basic option is to define the target architecture. For that, use
+<code class="docutils literal"><span class="pre">-target</span> <span class="pre"><triple></span></code>. If you donât specify the target, CPU names wonât
+match (since Clang assumes the host triple), and the compilation will
+go ahead, creating code for the host platform, which will break later
+on when assembling or linking.</p>
+<dl class="docutils">
+<dt>The triple has the general format <code class="docutils literal"><span class="pre"><arch><sub>-<vendor>-<sys>-<abi></span></code>, where:</dt>
+<dd><ul class="first last simple">
+<li><code class="docutils literal"><span class="pre">arch</span></code> = <code class="docutils literal"><span class="pre">x86_64</span></code>, <code class="docutils literal"><span class="pre">i386</span></code>, <code class="docutils literal"><span class="pre">arm</span></code>, <code class="docutils literal"><span class="pre">thumb</span></code>, <code class="docutils literal"><span class="pre">mips</span></code>, etc.</li>
+<li><code class="docutils literal"><span class="pre">sub</span></code> = for ex. on ARM: <code class="docutils literal"><span class="pre">v5</span></code>, <code class="docutils literal"><span class="pre">v6m</span></code>, <code class="docutils literal"><span class="pre">v7a</span></code>, <code class="docutils literal"><span class="pre">v7m</span></code>, etc.</li>
+<li><code class="docutils literal"><span class="pre">vendor</span></code> = <code class="docutils literal"><span class="pre">pc</span></code>, <code class="docutils literal"><span class="pre">apple</span></code>, <code class="docutils literal"><span class="pre">nvidia</span></code>, <code class="docutils literal"><span class="pre">ibm</span></code>, etc.</li>
+<li><code class="docutils literal"><span class="pre">sys</span></code> = <code class="docutils literal"><span class="pre">none</span></code>, <code class="docutils literal"><span class="pre">linux</span></code>, <code class="docutils literal"><span class="pre">win32</span></code>, <code class="docutils literal"><span class="pre">darwin</span></code>, <code class="docutils literal"><span class="pre">cuda</span></code>, etc.</li>
+<li><code class="docutils literal"><span class="pre">abi</span></code> = <code class="docutils literal"><span class="pre">eabi</span></code>, <code class="docutils literal"><span class="pre">gnu</span></code>, <code class="docutils literal"><span class="pre">android</span></code>, <code class="docutils literal"><span class="pre">macho</span></code>, <code class="docutils literal"><span class="pre">elf</span></code>, etc.</li>
+</ul>
+</dd>
+</dl>
+<p>The sub-architecture options are available for their own architectures,
+of course, so âx86v7aâ doesnât make sense. The vendor needs to be
+specified only if thereâs a relevant change, for instance between PC
+and Apple. Most of the time it can be omitted (and Unknown)
+will be assumed, which sets the defaults for the specified architecture.
+The system name is generally the OS (linux, darwin), but could be special
+like the bare-metal ânoneâ.</p>
+<p>When a parameter is not important, it can be omitted, or you can
+choose <code class="docutils literal"><span class="pre">unknown</span></code> and the defaults will be used. If you choose a parameter
+that Clang doesnât know, like <code class="docutils literal"><span class="pre">blerg</span></code>, itâll ignore and assume
+<code class="docutils literal"><span class="pre">unknown</span></code>, which is not always desired, so be careful.</p>
+<p>Finally, the ABI option is something that will pick default CPU/FPU,
+define the specific behaviour of your code (PCS, extensions),
+and also choose the correct library calls, etc.</p>
+</div>
+<div class="section" id="cpu-fpu-abi">
+<h3>CPU, FPU, ABI<a class="headerlink" href="#cpu-fpu-abi" title="Permalink to this headline">¶</a></h3>
+<p>Once your target is specified, itâs time to pick the hardware youâll
+be compiling to. For every architecture, a default set of CPU/FPU/ABI
+will be chosen, so youâll almost always have to change it via flags.</p>
+<dl class="docutils">
+<dt>Typical flags include:</dt>
+<dd><ul class="first last simple">
+<li><code class="docutils literal"><span class="pre">-mcpu=<cpu-name></span></code>, like x86-64, swift, cortex-a15</li>
+<li><code class="docutils literal"><span class="pre">-mfpu=<fpu-name></span></code>, like SSE3, NEON, controlling the FP unit available</li>
+<li><code class="docutils literal"><span class="pre">-mfloat-abi=<fabi></span></code>, like soft, hard, controlling which registers
+to use for floating-point</li>
+</ul>
+</dd>
+</dl>
+<p>The default is normally the common denominator, so that Clang doesnât
+generate code that breaks. But that also means you wonât get the best
+code for your specific hardware, which may mean orders of magnitude
+slower than you expect.</p>
+<p>For example, if your target is <code class="docutils literal"><span class="pre">arm-none-eabi</span></code>, the default CPU will
+be <code class="docutils literal"><span class="pre">arm7tdmi</span></code> using soft float, which is extremely slow on modern cores,
+whereas if your triple is <code class="docutils literal"><span class="pre">armv7a-none-eabi</span></code>, itâll be Cortex-A8 with
+NEON, but still using soft-float, which is much better, but still not
+great.</p>
+</div>
+<div class="section" id="toolchain-options">
+<h3>Toolchain Options<a class="headerlink" href="#toolchain-options" title="Permalink to this headline">¶</a></h3>
+<p>There are three main options to control access to your cross-compiler:
+<code class="docutils literal"><span class="pre">--sysroot</span></code>, <code class="docutils literal"><span class="pre">-I</span></code>, and <code class="docutils literal"><span class="pre">-L</span></code>. The two last ones are well known,
+but theyâre particularly important for additional libraries
+and headers that are specific to your target.</p>
+<p>There are two main ways to have a cross-compiler:</p>
+<ol class="arabic">
+<li><p class="first">When you have extracted your cross-compiler from a zip file into
+a directory, you have to use <code class="docutils literal"><span class="pre">--sysroot=<path></span></code>. The path is the
+root directory where you have unpacked your file, and Clang will
+look for the directories <code class="docutils literal"><span class="pre">bin</span></code>, <code class="docutils literal"><span class="pre">lib</span></code>, <code class="docutils literal"><span class="pre">include</span></code> in there.</p>
+<p>In this case, your setup should be pretty much done (if no
+additional headers or libraries are needed), as Clang will find
+all binaries it needs (assembler, linker, etc) in there.</p>
+</li>
+<li><p class="first">When you have installed via a package manager (modern Linux
+distributions have cross-compiler packages available), make
+sure the target triple you set is <em>also</em> the prefix of your
+cross-compiler toolchain.</p>
+<p>In this case, Clang will find the other binaries (assembler,
+linker), but not always where the target headers and libraries
+are. People add system-specific clues to Clang often, but as
+things change, itâs more likely that it wonât find than the
+other way around.</p>
+<p>So, here, youâll be a lot safer if you specify the include/library
+directories manually (via <code class="docutils literal"><span class="pre">-I</span></code> and <code class="docutils literal"><span class="pre">-L</span></code>).</p>
+</li>
+</ol>
+</div>
+</div>
+<div class="section" id="target-specific-libraries">
+<h2>Target-Specific Libraries<a class="headerlink" href="#target-specific-libraries" title="Permalink to this headline">¶</a></h2>
+<p>All libraries that you compile as part of your build will be
+cross-compiled to your target, and your build system will probably
+find them in the right place. But all dependencies that are
+normally checked against (like <code class="docutils literal"><span class="pre">libxml</span></code> or <code class="docutils literal"><span class="pre">libz</span></code> etc) will match
+against the host platform, not the target.</p>
+<p>So, if the build system is not aware that you want to cross-compile
+your code, it will get every dependency wrong, and your compilation
+will fail during build time, not configure time.</p>
+<p>Also, finding the libraries for your target are not as easy
+as for your host machine. There arenât many cross-libraries available
+as packages to most OSâs, so youâll have to either cross-compile them
+from source, or download the package for your target platform,
+extract the libraries and headers, put them in specific directories
+and add <code class="docutils literal"><span class="pre">-I</span></code> and <code class="docutils literal"><span class="pre">-L</span></code> pointing to them.</p>
+<p>Also, some libraries have different dependencies on different targets,
+so configuration tools to find dependencies in the host can get the
+list wrong for the target platform. This means that the configuration
+of your build can get things wrong when setting their own library
+paths, and youâll have to augment it via additional flags (configure,
+Make, CMake, etc).</p>
+<div class="section" id="multilibs">
+<h3>Multilibs<a class="headerlink" href="#multilibs" title="Permalink to this headline">¶</a></h3>
+<p>When you want to cross-compile to more than one configuration, for
+example hard-float-ARM and soft-float-ARM, youâll have to have multiple
+copies of your libraries and (possibly) headers.</p>
+<p>Some Linux distributions have support for Multilib, which handle that
+for you in an easier way, but if youâre not careful and, for instance,
+forget to specify <code class="docutils literal"><span class="pre">-ccc-gcc-name</span> <span class="pre">armv7l-linux-gnueabihf-gcc</span></code> (which
+uses hard-float), Clang will pick the <code class="docutils literal"><span class="pre">armv7l-linux-gnueabi-ld</span></code>
+(which uses soft-float) and linker errors will happen.</p>
+<p>The same is true if youâre compiling for different ABIs, like <code class="docutils literal"><span class="pre">gnueabi</span></code>
+and <code class="docutils literal"><span class="pre">androideabi</span></code>, and might even link and run, but produce run-time
+errors, which are much harder to track down and fix.</p>
+</div>
+</div>
+</div>
+
+
+ </div>
+ <div class="bottomnav" role="navigation" aria-label="bottom navigation">
+
+ <p>
+ « <a href="DiagnosticsReference.html">Diagnostic flags in Clang</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="ThreadSafetyAnalysis.html">Thread Safety Analysis</a> »
+ </p>
+
+ </div>
+
+ <div class="footer" role="contentinfo">
+ © Copyright 2007-2018, The Clang Team.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizer.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizer.html?rev=342530&view=auto
==============================================================================
--- www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizer.html (added)
+++ www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizer.html Wed Sep 19 02:40:08 2018
@@ -0,0 +1,220 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>DataFlowSanitizer — Clang 7 documentation</title>
+ <link rel="stylesheet" href="_static/haiku.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: './',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true,
+ SOURCELINK_SUFFIX: '.txt'
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="DataFlowSanitizer Design Document" href="DataFlowSanitizerDesign.html" />
+ <link rel="prev" title="UndefinedBehaviorSanitizer" href="UndefinedBehaviorSanitizer.html" />
+ </head>
+ <body>
+ <div class="header" role="banner"><h1 class="heading"><a href="index.html">
+ <span>Clang 7 documentation</span></a></h1>
+ <h2 class="heading"><span>DataFlowSanitizer</span></h2>
+ </div>
+ <div class="topnav" role="navigation" aria-label="top navigation">
+
+ <p>
+ « <a href="UndefinedBehaviorSanitizer.html">UndefinedBehaviorSanitizer</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="DataFlowSanitizerDesign.html">DataFlowSanitizer Design Document</a> »
+ </p>
+
+ </div>
+ <div class="content">
+
+
+ <div class="section" id="dataflowsanitizer">
+<h1>DataFlowSanitizer<a class="headerlink" href="#dataflowsanitizer" title="Permalink to this headline">¶</a></h1>
+<div class="toctree-wrapper compound">
+</div>
+<div class="contents local topic" id="contents">
+<ul class="simple">
+<li><a class="reference internal" href="#introduction" id="id1">Introduction</a></li>
+<li><a class="reference internal" href="#usage" id="id2">Usage</a><ul>
+<li><a class="reference internal" href="#abi-list" id="id3">ABI List</a></li>
+</ul>
+</li>
+<li><a class="reference internal" href="#example" id="id4">Example</a></li>
+<li><a class="reference internal" href="#current-status" id="id5">Current status</a></li>
+<li><a class="reference internal" href="#design" id="id6">Design</a></li>
+</ul>
+</div>
+<div class="section" id="introduction">
+<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
+<p>DataFlowSanitizer is a generalised dynamic data flow analysis.</p>
+<p>Unlike other Sanitizer tools, this tool is not designed to detect a
+specific class of bugs on its own. Instead, it provides a generic
+dynamic data flow analysis framework to be used by clients to help
+detect application-specific issues within their own code.</p>
+</div>
+<div class="section" id="usage">
+<h2><a class="toc-backref" href="#id2">Usage</a><a class="headerlink" href="#usage" title="Permalink to this headline">¶</a></h2>
+<p>With no program changes, applying DataFlowSanitizer to a program
+will not alter its behavior. To use DataFlowSanitizer, the program
+uses API functions to apply tags to data to cause it to be tracked, and to
+check the tag of a specific data item. DataFlowSanitizer manages
+the propagation of tags through the program according to its data flow.</p>
+<p>The APIs are defined in the header file <code class="docutils literal"><span class="pre">sanitizer/dfsan_interface.h</span></code>.
+For further information about each function, please refer to the header
+file.</p>
+<div class="section" id="abi-list">
+<h3><a class="toc-backref" href="#id3">ABI List</a><a class="headerlink" href="#abi-list" title="Permalink to this headline">¶</a></h3>
+<p>DataFlowSanitizer uses a list of functions known as an ABI list to decide
+whether a call to a specific function should use the operating systemâs native
+ABI or whether it should use a variant of this ABI that also propagates labels
+through function parameters and return values. The ABI list file also controls
+how labels are propagated in the former case. DataFlowSanitizer comes with a
+default ABI list which is intended to eventually cover the glibc library on
+Linux but it may become necessary for users to extend the ABI list in cases
+where a particular library or function cannot be instrumented (e.g. because
+it is implemented in assembly or another language which DataFlowSanitizer does
+not support) or a function is called from a library or function which cannot
+be instrumented.</p>
+<p>DataFlowSanitizerâs ABI list file is a <a class="reference internal" href="SanitizerSpecialCaseList.html"><span class="doc">Sanitizer special case list</span></a>.
+The pass treats every function in the <code class="docutils literal"><span class="pre">uninstrumented</span></code> category in the
+ABI list file as conforming to the native ABI. Unless the ABI list contains
+additional categories for those functions, a call to one of those functions
+will produce a warning message, as the labelling behavior of the function
+is unknown. The other supported categories are <code class="docutils literal"><span class="pre">discard</span></code>, <code class="docutils literal"><span class="pre">functional</span></code>
+and <code class="docutils literal"><span class="pre">custom</span></code>.</p>
+<ul class="simple">
+<li><code class="docutils literal"><span class="pre">discard</span></code> â To the extent that this function writes to (user-accessible)
+memory, it also updates labels in shadow memory (this condition is trivially
+satisfied for functions which do not write to user-accessible memory). Its
+return value is unlabelled.</li>
+<li><code class="docutils literal"><span class="pre">functional</span></code> â Like <code class="docutils literal"><span class="pre">discard</span></code>, except that the label of its return value
+is the union of the label of its arguments.</li>
+<li><code class="docutils literal"><span class="pre">custom</span></code> â Instead of calling the function, a custom wrapper <code class="docutils literal"><span class="pre">__dfsw_F</span></code>
+is called, where <code class="docutils literal"><span class="pre">F</span></code> is the name of the function. This function may wrap
+the original function or provide its own implementation. This category is
+generally used for uninstrumentable functions which write to user-accessible
+memory or which have more complex label propagation behavior. The signature
+of <code class="docutils literal"><span class="pre">__dfsw_F</span></code> is based on that of <code class="docutils literal"><span class="pre">F</span></code> with each argument having a
+label of type <code class="docutils literal"><span class="pre">dfsan_label</span></code> appended to the argument list. If <code class="docutils literal"><span class="pre">F</span></code>
+is of non-void return type a final argument of type <code class="docutils literal"><span class="pre">dfsan_label</span> <span class="pre">*</span></code>
+is appended to which the custom function can store the label for the
+return value. For example:</li>
+</ul>
+<div class="highlight-c++"><div class="highlight"><pre><span></span><span class="kt">void</span> <span class="nf">f</span><span class="p">(</span><span class="kt">int</span> <span class="n">x</span><span class="p">);</span>
+<span class="kt">void</span> <span class="nf">__dfsw_f</span><span class="p">(</span><span class="kt">int</span> <span class="n">x</span><span class="p">,</span> <span class="n">dfsan_label</span> <span class="n">x_label</span><span class="p">);</span>
+
+<span class="kt">void</span> <span class="o">*</span><span class="nf">memcpy</span><span class="p">(</span><span class="kt">void</span> <span class="o">*</span><span class="n">dest</span><span class="p">,</span> <span class="k">const</span> <span class="kt">void</span> <span class="o">*</span><span class="n">src</span><span class="p">,</span> <span class="kt">size_t</span> <span class="n">n</span><span class="p">);</span>
+<span class="kt">void</span> <span class="o">*</span><span class="nf">__dfsw_memcpy</span><span class="p">(</span><span class="kt">void</span> <span class="o">*</span><span class="n">dest</span><span class="p">,</span> <span class="k">const</span> <span class="kt">void</span> <span class="o">*</span><span class="n">src</span><span class="p">,</span> <span class="kt">size_t</span> <span class="n">n</span><span class="p">,</span>
+ <span class="n">dfsan_label</span> <span class="n">dest_label</span><span class="p">,</span> <span class="n">dfsan_label</span> <span class="n">src_label</span><span class="p">,</span>
+ <span class="n">dfsan_label</span> <span class="n">n_label</span><span class="p">,</span> <span class="n">dfsan_label</span> <span class="o">*</span><span class="n">ret_label</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>If a function defined in the translation unit being compiled belongs to the
+<code class="docutils literal"><span class="pre">uninstrumented</span></code> category, it will be compiled so as to conform to the
+native ABI. Its arguments will be assumed to be unlabelled, but it will
+propagate labels in shadow memory.</p>
+<p>For example:</p>
+<div class="highlight-none"><div class="highlight"><pre><span></span># main is called by the C runtime using the native ABI.
+fun:main=uninstrumented
+fun:main=discard
+
+# malloc only writes to its internal data structures, not user-accessible memory.
+fun:malloc=uninstrumented
+fun:malloc=discard
+
+# tolower is a pure function.
+fun:tolower=uninstrumented
+fun:tolower=functional
+
+# memcpy needs to copy the shadow from the source to the destination region.
+# This is done in a custom function.
+fun:memcpy=uninstrumented
+fun:memcpy=custom
+</pre></div>
+</div>
+</div>
+</div>
+<div class="section" id="example">
+<h2><a class="toc-backref" href="#id4">Example</a><a class="headerlink" href="#example" title="Permalink to this headline">¶</a></h2>
+<p>The following program demonstrates label propagation by checking that
+the correct labels are propagated.</p>
+<div class="highlight-c++"><div class="highlight"><pre><span></span><span class="cp">#include</span> <span class="cpf"><sanitizer/dfsan_interface.h></span><span class="cp"></span>
+<span class="cp">#include</span> <span class="cpf"><assert.h></span><span class="cp"></span>
+
+<span class="kt">int</span> <span class="nf">main</span><span class="p">(</span><span class="kt">void</span><span class="p">)</span> <span class="p">{</span>
+ <span class="kt">int</span> <span class="n">i</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
+ <span class="n">dfsan_label</span> <span class="n">i_label</span> <span class="o">=</span> <span class="n">dfsan_create_label</span><span class="p">(</span><span class="s">"i"</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
+ <span class="n">dfsan_set_label</span><span class="p">(</span><span class="n">i_label</span><span class="p">,</span> <span class="o">&</span><span class="n">i</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="n">i</span><span class="p">));</span>
+
+ <span class="kt">int</span> <span class="n">j</span> <span class="o">=</span> <span class="mi">2</span><span class="p">;</span>
+ <span class="n">dfsan_label</span> <span class="n">j_label</span> <span class="o">=</span> <span class="n">dfsan_create_label</span><span class="p">(</span><span class="s">"j"</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
+ <span class="n">dfsan_set_label</span><span class="p">(</span><span class="n">j_label</span><span class="p">,</span> <span class="o">&</span><span class="n">j</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="n">j</span><span class="p">));</span>
+
+ <span class="kt">int</span> <span class="n">k</span> <span class="o">=</span> <span class="mi">3</span><span class="p">;</span>
+ <span class="n">dfsan_label</span> <span class="n">k_label</span> <span class="o">=</span> <span class="n">dfsan_create_label</span><span class="p">(</span><span class="s">"k"</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
+ <span class="n">dfsan_set_label</span><span class="p">(</span><span class="n">k_label</span><span class="p">,</span> <span class="o">&</span><span class="n">k</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="n">k</span><span class="p">));</span>
+
+ <span class="n">dfsan_label</span> <span class="n">ij_label</span> <span class="o">=</span> <span class="n">dfsan_get_label</span><span class="p">(</span><span class="n">i</span> <span class="o">+</span> <span class="n">j</span><span class="p">);</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">dfsan_has_label</span><span class="p">(</span><span class="n">ij_label</span><span class="p">,</span> <span class="n">i_label</span><span class="p">));</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">dfsan_has_label</span><span class="p">(</span><span class="n">ij_label</span><span class="p">,</span> <span class="n">j_label</span><span class="p">));</span>
+ <span class="n">assert</span><span class="p">(</span><span class="o">!</span><span class="n">dfsan_has_label</span><span class="p">(</span><span class="n">ij_label</span><span class="p">,</span> <span class="n">k_label</span><span class="p">));</span>
+
+ <span class="n">dfsan_label</span> <span class="n">ijk_label</span> <span class="o">=</span> <span class="n">dfsan_get_label</span><span class="p">(</span><span class="n">i</span> <span class="o">+</span> <span class="n">j</span> <span class="o">+</span> <span class="n">k</span><span class="p">);</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">dfsan_has_label</span><span class="p">(</span><span class="n">ijk_label</span><span class="p">,</span> <span class="n">i_label</span><span class="p">));</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">dfsan_has_label</span><span class="p">(</span><span class="n">ijk_label</span><span class="p">,</span> <span class="n">j_label</span><span class="p">));</span>
+ <span class="n">assert</span><span class="p">(</span><span class="n">dfsan_has_label</span><span class="p">(</span><span class="n">ijk_label</span><span class="p">,</span> <span class="n">k_label</span><span class="p">));</span>
+
+ <span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="current-status">
+<h2><a class="toc-backref" href="#id5">Current status</a><a class="headerlink" href="#current-status" title="Permalink to this headline">¶</a></h2>
+<p>DataFlowSanitizer is a work in progress, currently under development for
+x86_64 Linux.</p>
+</div>
+<div class="section" id="design">
+<h2><a class="toc-backref" href="#id6">Design</a><a class="headerlink" href="#design" title="Permalink to this headline">¶</a></h2>
+<p>Please refer to the <a class="reference internal" href="DataFlowSanitizerDesign.html"><span class="doc">design document</span></a>.</p>
+</div>
+</div>
+
+
+ </div>
+ <div class="bottomnav" role="navigation" aria-label="bottom navigation">
+
+ <p>
+ « <a href="UndefinedBehaviorSanitizer.html">UndefinedBehaviorSanitizer</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="DataFlowSanitizerDesign.html">DataFlowSanitizer Design Document</a> »
+ </p>
+
+ </div>
+
+ <div class="footer" role="contentinfo">
+ © Copyright 2007-2018, The Clang Team.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
Added: www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizerDesign.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizerDesign.html?rev=342530&view=auto
==============================================================================
--- www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizerDesign.html (added)
+++ www-releases/trunk/7.0.0/tools/clang/docs/DataFlowSanitizerDesign.html Wed Sep 19 02:40:08 2018
@@ -0,0 +1,289 @@
+
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <title>DataFlowSanitizer Design Document — Clang 7 documentation</title>
+ <link rel="stylesheet" href="_static/haiku.css" type="text/css" />
+ <link rel="stylesheet" href="_static/pygments.css" type="text/css" />
+ <script type="text/javascript">
+ var DOCUMENTATION_OPTIONS = {
+ URL_ROOT: './',
+ VERSION: '7',
+ COLLAPSE_INDEX: false,
+ FILE_SUFFIX: '.html',
+ HAS_SOURCE: true,
+ SOURCELINK_SUFFIX: '.txt'
+ };
+ </script>
+ <script type="text/javascript" src="_static/jquery.js"></script>
+ <script type="text/javascript" src="_static/underscore.js"></script>
+ <script type="text/javascript" src="_static/doctools.js"></script>
+ <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
+ <link rel="index" title="Index" href="genindex.html" />
+ <link rel="search" title="Search" href="search.html" />
+ <link rel="next" title="LeakSanitizer" href="LeakSanitizer.html" />
+ <link rel="prev" title="DataFlowSanitizer" href="DataFlowSanitizer.html" />
+ </head>
+ <body>
+ <div class="header" role="banner"><h1 class="heading"><a href="index.html">
+ <span>Clang 7 documentation</span></a></h1>
+ <h2 class="heading"><span>DataFlowSanitizer Design Document</span></h2>
+ </div>
+ <div class="topnav" role="navigation" aria-label="top navigation">
+
+ <p>
+ « <a href="DataFlowSanitizer.html">DataFlowSanitizer</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="LeakSanitizer.html">LeakSanitizer</a> »
+ </p>
+
+ </div>
+ <div class="content">
+
+
+ <div class="section" id="dataflowsanitizer-design-document">
+<h1>DataFlowSanitizer Design Document<a class="headerlink" href="#dataflowsanitizer-design-document" title="Permalink to this headline">¶</a></h1>
+<p>This document sets out the design for DataFlowSanitizer, a general
+dynamic data flow analysis. Unlike other Sanitizer tools, this tool is
+not designed to detect a specific class of bugs on its own. Instead,
+it provides a generic dynamic data flow analysis framework to be used
+by clients to help detect application-specific issues within their
+own code.</p>
+<p>DataFlowSanitizer is a program instrumentation which can associate
+a number of taint labels with any data stored in any memory region
+accessible by the program. The analysis is dynamic, which means that
+it operates on a running program, and tracks how the labels propagate
+through that program. The tool shall support a large (>100) number
+of labels, such that programs which operate on large numbers of data
+items may be analysed with each data item being tracked separately.</p>
+<div class="section" id="use-cases">
+<h2>Use Cases<a class="headerlink" href="#use-cases" title="Permalink to this headline">¶</a></h2>
+<p>This instrumentation can be used as a tool to help monitor how data
+flows from a programâs inputs (sources) to its outputs (sinks).
+This has applications from a privacy/security perspective in that
+one can audit how a sensitive data item is used within a program and
+ensure it isnât exiting the program anywhere it shouldnât be.</p>
+</div>
+<div class="section" id="interface">
+<h2>Interface<a class="headerlink" href="#interface" title="Permalink to this headline">¶</a></h2>
+<p>A number of functions are provided which will create taint labels,
+attach labels to memory regions and extract the set of labels
+associated with a specific memory region. These functions are declared
+in the header file <code class="docutils literal"><span class="pre">sanitizer/dfsan_interface.h</span></code>.</p>
+<div class="highlight-c"><div class="highlight"><pre><span></span><span class="c1">/// Creates and returns a base label with the given description and user data.</span>
+<span class="n">dfsan_label</span> <span class="nf">dfsan_create_label</span><span class="p">(</span><span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">desc</span><span class="p">,</span> <span class="kt">void</span> <span class="o">*</span><span class="n">userdata</span><span class="p">);</span>
+
+<span class="c1">/// Sets the label for each address in [addr,addr+size) to \c label.</span>
+<span class="kt">void</span> <span class="nf">dfsan_set_label</span><span class="p">(</span><span class="n">dfsan_label</span> <span class="n">label</span><span class="p">,</span> <span class="kt">void</span> <span class="o">*</span><span class="n">addr</span><span class="p">,</span> <span class="kt">size_t</span> <span class="n">size</span><span class="p">);</span>
+
+<span class="c1">/// Sets the label for each address in [addr,addr+size) to the union of the</span>
+<span class="c1">/// current label for that address and \c label.</span>
+<span class="kt">void</span> <span class="nf">dfsan_add_label</span><span class="p">(</span><span class="n">dfsan_label</span> <span class="n">label</span><span class="p">,</span> <span class="kt">void</span> <span class="o">*</span><span class="n">addr</span><span class="p">,</span> <span class="kt">size_t</span> <span class="n">size</span><span class="p">);</span>
+
+<span class="c1">/// Retrieves the label associated with the given data.</span>
+<span class="c1">///</span>
+<span class="c1">/// The type of 'data' is arbitrary. The function accepts a value of any type,</span>
+<span class="c1">/// which can be truncated or extended (implicitly or explicitly) as necessary.</span>
+<span class="c1">/// The truncation/extension operations will preserve the label of the original</span>
+<span class="c1">/// value.</span>
+<span class="n">dfsan_label</span> <span class="nf">dfsan_get_label</span><span class="p">(</span><span class="kt">long</span> <span class="n">data</span><span class="p">);</span>
+
+<span class="c1">/// Retrieves a pointer to the dfsan_label_info struct for the given label.</span>
+<span class="k">const</span> <span class="k">struct</span> <span class="n">dfsan_label_info</span> <span class="o">*</span><span class="nf">dfsan_get_label_info</span><span class="p">(</span><span class="n">dfsan_label</span> <span class="n">label</span><span class="p">);</span>
+
+<span class="c1">/// Returns whether the given label label contains the label elem.</span>
+<span class="kt">int</span> <span class="nf">dfsan_has_label</span><span class="p">(</span><span class="n">dfsan_label</span> <span class="n">label</span><span class="p">,</span> <span class="n">dfsan_label</span> <span class="n">elem</span><span class="p">);</span>
+
+<span class="c1">/// If the given label label contains a label with the description desc, returns</span>
+<span class="c1">/// that label, else returns 0.</span>
+<span class="n">dfsan_label</span> <span class="nf">dfsan_has_label_with_desc</span><span class="p">(</span><span class="n">dfsan_label</span> <span class="n">label</span><span class="p">,</span> <span class="k">const</span> <span class="kt">char</span> <span class="o">*</span><span class="n">desc</span><span class="p">);</span>
+</pre></div>
+</div>
+</div>
+<div class="section" id="taint-label-representation">
+<h2>Taint label representation<a class="headerlink" href="#taint-label-representation" title="Permalink to this headline">¶</a></h2>
+<p>As stated above, the tool must track a large number of taint
+labels. This poses an implementation challenge, as most multiple-label
+tainting systems assign one label per bit to shadow storage, and
+union taint labels using a bitwise or operation. This will not scale
+to clients which use hundreds or thousands of taint labels, as the
+label union operation becomes O(n) in the number of supported labels,
+and data associated with it will quickly dominate the live variable
+set, causing register spills and hampering performance.</p>
+<p>Instead, a low overhead approach is proposed which is best-case O(log<sub>2</sub> n) during execution. The underlying assumption is that
+the required space of label unions is sparse, which is a reasonable
+assumption to make given that we are optimizing for the case where
+applications mostly copy data from one place to another, without often
+invoking the need for an actual union operation. The representation
+of a taint label is a 16-bit integer, and new labels are allocated
+sequentially from a pool. The label identifier 0 is special, and means
+that the data item is unlabelled.</p>
+<p>When a label union operation is requested at a join point (any
+arithmetic or logical operation with two or more operands, such as
+addition), the code checks whether a union is required, whether the
+same union has been requested before, and whether one union label
+subsumes the other. If so, it returns the previously allocated union
+label. If not, it allocates a new union label from the same pool used
+for new labels.</p>
+<p>Specifically, the instrumentation pass will insert code like this
+to decide the union label <code class="docutils literal"><span class="pre">lu</span></code> for a pair of labels <code class="docutils literal"><span class="pre">l1</span></code>
+and <code class="docutils literal"><span class="pre">l2</span></code>:</p>
+<div class="highlight-c"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="p">(</span><span class="n">l1</span> <span class="o">==</span> <span class="n">l2</span><span class="p">)</span>
+ <span class="n">lu</span> <span class="o">=</span> <span class="n">l1</span><span class="p">;</span>
+<span class="k">else</span>
+ <span class="n">lu</span> <span class="o">=</span> <span class="n">__dfsan_union</span><span class="p">(</span><span class="n">l1</span><span class="p">,</span> <span class="n">l2</span><span class="p">);</span>
+</pre></div>
+</div>
+<p>The equality comparison is outlined, to provide an early exit in
+the common cases where the program is processing unlabelled data, or
+where the two data items have the same label. <code class="docutils literal"><span class="pre">__dfsan_union</span></code> is
+a runtime library function which performs all other union computation.</p>
+<p>Further optimizations are possible, for example if <code class="docutils literal"><span class="pre">l1</span></code> is known
+at compile time to be zero (e.g. it is derived from a constant),
+<code class="docutils literal"><span class="pre">l2</span></code> can be used for <code class="docutils literal"><span class="pre">lu</span></code>, and vice versa.</p>
+</div>
+<div class="section" id="memory-layout-and-label-management">
+<h2>Memory layout and label management<a class="headerlink" href="#memory-layout-and-label-management" title="Permalink to this headline">¶</a></h2>
+<p>The following is the current memory layout for Linux/x86_64:</p>
+<table border="1" class="docutils">
+<colgroup>
+<col width="30%" />
+<col width="30%" />
+<col width="40%" />
+</colgroup>
+<thead valign="bottom">
+<tr class="row-odd"><th class="head">Start</th>
+<th class="head">End</th>
+<th class="head">Use</th>
+</tr>
+</thead>
+<tbody valign="top">
+<tr class="row-even"><td>0x700000008000</td>
+<td>0x800000000000</td>
+<td>application memory</td>
+</tr>
+<tr class="row-odd"><td>0x200200000000</td>
+<td>0x700000008000</td>
+<td>unused</td>
+</tr>
+<tr class="row-even"><td>0x200000000000</td>
+<td>0x200200000000</td>
+<td>union table</td>
+</tr>
+<tr class="row-odd"><td>0x000000010000</td>
+<td>0x200000000000</td>
+<td>shadow memory</td>
+</tr>
+<tr class="row-even"><td>0x000000000000</td>
+<td>0x000000010000</td>
+<td>reserved by kernel</td>
+</tr>
+</tbody>
+</table>
+<p>Each byte of application memory corresponds to two bytes of shadow
+memory, which are used to store its taint label. As for LLVM SSA
+registers, we have not found it necessary to associate a label with
+each byte or bit of data, as some other tools do. Instead, labels are
+associated directly with registers. Loads will result in a union of
+all shadow labels corresponding to bytes loaded (which most of the
+time will be short circuited by the initial comparison) and stores will
+result in a copy of the label to the shadow of all bytes stored to.</p>
+</div>
+<div class="section" id="propagating-labels-through-arguments">
+<h2>Propagating labels through arguments<a class="headerlink" href="#propagating-labels-through-arguments" title="Permalink to this headline">¶</a></h2>
+<p>In order to propagate labels through function arguments and return values,
+DataFlowSanitizer changes the ABI of each function in the translation unit.
+There are currently two supported ABIs:</p>
+<ul class="simple">
+<li>Args â Argument and return value labels are passed through additional
+arguments and by modifying the return type.</li>
+<li>TLS â Argument and return value labels are passed through TLS variables
+<code class="docutils literal"><span class="pre">__dfsan_arg_tls</span></code> and <code class="docutils literal"><span class="pre">__dfsan_retval_tls</span></code>.</li>
+</ul>
+<p>The main advantage of the TLS ABI is that it is more tolerant of ABI mismatches
+(TLS storage is not shared with any other form of storage, whereas extra
+arguments may be stored in registers which under the native ABI are not used
+for parameter passing and thus could contain arbitrary values). On the other
+hand the args ABI is more efficient and allows ABI mismatches to be more easily
+identified by checking for nonzero labels in nominally unlabelled programs.</p>
+</div>
+<div class="section" id="implementing-the-abi-list">
+<h2>Implementing the ABI list<a class="headerlink" href="#implementing-the-abi-list" title="Permalink to this headline">¶</a></h2>
+<p>The <a class="reference external" href="DataFlowSanitizer.html#abi-list">ABI list</a> provides a list of functions
+which conform to the native ABI, each of which is callable from an instrumented
+program. This is implemented by replacing each reference to a native ABI
+function with a reference to a function which uses the instrumented ABI.
+Such functions are automatically-generated wrappers for the native functions.
+For example, given the ABI list example provided in the user manual, the
+following wrappers will be generated under the args ABI:</p>
+<div class="highlight-llvm"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">linkonce_odr</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="vg">@"dfsw$malloc"</span><span class="p">(</span><span class="k">i64</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%1</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+ <span class="nv nv-Anonymous">%2</span> <span class="p">=</span> <span class="k">call</span> <span class="k">i8</span><span class="p">*</span> <span class="vg">@malloc</span><span class="p">(</span><span class="k">i64</span> <span class="nv nv-Anonymous">%0</span><span class="p">)</span>
+ <span class="nv nv-Anonymous">%3</span> <span class="p">=</span> <span class="k">insertvalue</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="k">undef</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv nv-Anonymous">%2</span><span class="p">,</span> <span class="m">0</span>
+ <span class="nv nv-Anonymous">%4</span> <span class="p">=</span> <span class="k">insertvalue</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="nv nv-Anonymous">%3</span><span class="p">,</span> <span class="k">i16</span> <span class="m">0</span><span class="p">,</span> <span class="m">1</span>
+ <span class="k">ret</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="nv nv-Anonymous">%4</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="k">linkonce_odr</span> <span class="p">{</span> <span class="k">i32</span><span class="p">,</span> <span class="k">i16</span> <span class="p">}</span> <span class="vg">@"dfsw$tolower"</span><span class="p">(</span><span class="k">i32</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%1</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+ <span class="nv nv-Anonymous">%2</span> <span class="p">=</span> <span class="k">call</span> <span class="k">i32</span> <span class="vg">@tolower</span><span class="p">(</span><span class="k">i32</span> <span class="nv nv-Anonymous">%0</span><span class="p">)</span>
+ <span class="nv nv-Anonymous">%3</span> <span class="p">=</span> <span class="k">insertvalue</span> <span class="p">{</span> <span class="k">i32</span><span class="p">,</span> <span class="k">i16</span> <span class="p">}</span> <span class="k">undef</span><span class="p">,</span> <span class="k">i32</span> <span class="nv nv-Anonymous">%2</span><span class="p">,</span> <span class="m">0</span>
+ <span class="nv nv-Anonymous">%4</span> <span class="p">=</span> <span class="k">insertvalue</span> <span class="p">{</span> <span class="k">i32</span><span class="p">,</span> <span class="k">i16</span> <span class="p">}</span> <span class="nv nv-Anonymous">%3</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%1</span><span class="p">,</span> <span class="m">1</span>
+ <span class="k">ret</span> <span class="p">{</span> <span class="k">i32</span><span class="p">,</span> <span class="k">i16</span> <span class="p">}</span> <span class="nv nv-Anonymous">%4</span>
+<span class="p">}</span>
+
+<span class="k">define</span> <span class="k">linkonce_odr</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="vg">@"dfsw$memcpy"</span><span class="p">(</span><span class="k">i8</span><span class="p">*</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv nv-Anonymous">%1</span><span class="p">,</span> <span class="k">i64</span> <span class="nv nv-Anonymous">%2</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%3</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%4</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%5</span><span class="p">)</span> <span class="p">{</span>
+<span class="nl">entry:</span>
+ <span class="nv">%labelreturn</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i16</span>
+ <span class="nv nv-Anonymous">%6</span> <span class="p">=</span> <span class="k">call</span> <span class="k">i8</span><span class="p">*</span> <span class="vg">@__dfsw_memcpy</span><span class="p">(</span><span class="k">i8</span><span class="p">*</span> <span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv nv-Anonymous">%1</span><span class="p">,</span> <span class="k">i64</span> <span class="nv nv-Anonymous">%2</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%3</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%4</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%5</span><span class="p">,</span> <span class="k">i16</span><span class="p">*</span> <span class="nv">%labelreturn</span><span class="p">)</span>
+ <span class="nv nv-Anonymous">%7</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i16</span><span class="p">*</span> <span class="nv">%labelreturn</span>
+ <span class="nv nv-Anonymous">%8</span> <span class="p">=</span> <span class="k">insertvalue</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="k">undef</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv nv-Anonymous">%6</span><span class="p">,</span> <span class="m">0</span>
+ <span class="nv nv-Anonymous">%9</span> <span class="p">=</span> <span class="k">insertvalue</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="nv nv-Anonymous">%8</span><span class="p">,</span> <span class="k">i16</span> <span class="nv nv-Anonymous">%7</span><span class="p">,</span> <span class="m">1</span>
+ <span class="k">ret</span> <span class="p">{</span> <span class="k">i8</span><span class="p">*,</span> <span class="k">i16</span> <span class="p">}</span> <span class="nv nv-Anonymous">%9</span>
+<span class="p">}</span>
+</pre></div>
+</div>
+<p>As an optimization, direct calls to native ABI functions will call the
+native ABI function directly and the pass will compute the appropriate label
+internally. This has the advantage of reducing the number of union operations
+required when the return value label is known to be zero (i.e. <code class="docutils literal"><span class="pre">discard</span></code>
+functions, or <code class="docutils literal"><span class="pre">functional</span></code> functions with known unlabelled arguments).</p>
+</div>
+<div class="section" id="checking-abi-consistency">
+<h2>Checking ABI Consistency<a class="headerlink" href="#checking-abi-consistency" title="Permalink to this headline">¶</a></h2>
+<p>DFSan changes the ABI of each function in the module. This makes it possible
+for a function with the native ABI to be called with the instrumented ABI,
+or vice versa, thus possibly invoking undefined behavior. A simple way
+of statically detecting instances of this problem is to prepend the prefix
+âdfs$â to the name of each instrumented-ABI function.</p>
+<p>This will not catch every such problem; in particular function pointers passed
+across the instrumented-native barrier cannot be used on the other side.
+These problems could potentially be caught dynamically.</p>
+</div>
+</div>
+
+
+ </div>
+ <div class="bottomnav" role="navigation" aria-label="bottom navigation">
+
+ <p>
+ « <a href="DataFlowSanitizer.html">DataFlowSanitizer</a>
+ ::
+ <a class="uplink" href="index.html">Contents</a>
+ ::
+ <a href="LeakSanitizer.html">LeakSanitizer</a> »
+ </p>
+
+ </div>
+
+ <div class="footer" role="contentinfo">
+ © Copyright 2007-2018, The Clang Team.
+ Created using <a href="http://sphinx-doc.org/">Sphinx</a> 1.6.4.
+ </div>
+ </body>
+</html>
\ No newline at end of file
More information about the llvm-commits
mailing list