| OLD | NEW |
|---|
| (Empty) | |
| 1 {{+bindTo:partials.standard_nacl_article}} |
| 2 |
| 3 <section id="pnacl-undefined-behavior"> |
| 4 <h1 id="pnacl-undefined-behavior">PNaCl Undefined Behavior</h1> |
| 5 <div class="contents local" id="contents" style="display: none"> |
| 6 <ul class="small-gap"> |
| 7 <li><a class="reference internal" href="#overview" id="id2">Overview</a></li> |
| 8 <li><a class="reference internal" href="#specification" id="id3">Specification</
a></li> |
| 9 <li><p class="first"><a class="reference internal" href="#behavior-in-pnacl-bitc
ode" id="id4">Behavior in PNaCl Bitcode</a></p> |
| 10 <ul class="small-gap"> |
| 11 <li><a class="reference internal" href="#well-defined" id="id5">Well-Defined</a>
</li> |
| 12 <li><p class="first"><a class="reference internal" href="#not-well-defined" id="
id6">Not Well-Defined</a></p> |
| 13 <ul class="small-gap"> |
| 14 <li><a class="reference internal" href="#potentially-fixable" id="id7">Potential
ly Fixable</a></li> |
| 15 <li><a class="reference internal" href="#floating-point" id="id8">Floating-Point
</a></li> |
| 16 <li><a class="reference internal" href="#hard-to-fix" id="id9">Hard to Fix</a></
li> |
| 17 </ul> |
| 18 </li> |
| 19 </ul> |
| 20 </li> |
| 21 </ul> |
| 22 |
| 23 </div><section id="overview"> |
| 24 <span id="undefined-behavior"></span><h2 id="overview"><span id="undefined-behav
ior"></span>Overview</h2> |
| 25 <p>C and C++ undefined behavior allows efficient mapping of the source |
| 26 language onto hardware, but leads to different behavior on different |
| 27 platforms.</p> |
| 28 <p>PNaCl exposes undefined behavior in the following ways:</p> |
| 29 <ul class="small-gap"> |
| 30 <li><p class="first">The Clang frontend and optimizations that occur on the deve
loper’s |
| 31 machine determine what behavior will occur, and it will be specified |
| 32 deterministically in the <em>pexe</em>. All targets will observe the same |
| 33 behavior. In some cases, recompiling with a newer PNaCl SDK version |
| 34 will either:</p> |
| 35 <ul class="small-gap"> |
| 36 <li>Reliably emit the same behavior in the resulting <em>pexe</em>.</li> |
| 37 <li>Change the behavior that gets specified in the <em>pexe</em>.</li> |
| 38 </ul> |
| 39 </li> |
| 40 <li><p class="first">The behavior specified in the <em>pexe</em> relies on PNaCl
’s bitcode, |
| 41 runtime or CPU architecture vagaries.</p> |
| 42 <ul class="small-gap"> |
| 43 <li>In some cases, the behavior using the same PNaCl translator version |
| 44 on different architectures will produce different behavior.</li> |
| 45 <li>Sometimes runtime parameters determine the behavior, e.g. memory |
| 46 allocation determines which out-of-bounds accesses crash versus |
| 47 returning garbage.</li> |
| 48 <li>In some cases, different versions of the PNaCl translator |
| 49 (i.e. after a Chrome update) will compile the code differently and |
| 50 cause different behavior.</li> |
| 51 <li>In some cases, the same versions of the PNaCl translator, on the |
| 52 same architecture, will generate a different <em>nexe</em> for |
| 53 defense-in-depth purposes, but may cause code that reads invalid |
| 54 stack values or code sections on the heap to observe these |
| 55 randomizations.</li> |
| 56 </ul> |
| 57 </li> |
| 58 </ul> |
| 59 </section><section id="specification"> |
| 60 <h2 id="specification">Specification</h2> |
| 61 <p>PNaCl’s goal is that a single <em>pexe</em> should work reliably in the
same |
| 62 manner on all architectures, irrespective of runtime parameters and |
| 63 through Chrome updates. This goal is unfortunately not attainable; PNaCl |
| 64 therefore specifies as much as it can and outlines areas for |
| 65 improvement.</p> |
| 66 <p>One interesting solution is to offer good support for LLVM’s sanitizer |
| 67 tools (including <a class="reference external" href="http://clang.llvm.org/docs/
UsersManual.html#controlling-code-generation">UBSan</a>) |
| 68 at development time, so that developers can test their code against |
| 69 undefined behavior. Shipping code would then still get good performance, |
| 70 and diverging behavior would be rare.</p> |
| 71 <p>Note that none of these issues are vulnerabilities in PNaCl and Chrome: |
| 72 the NaCl sandboxing still constrains the code through Software Fault |
| 73 Isolation.</p> |
| 74 </section><section id="behavior-in-pnacl-bitcode"> |
| 75 <h2 id="behavior-in-pnacl-bitcode">Behavior in PNaCl Bitcode</h2> |
| 76 <section id="well-defined"> |
| 77 <h3 id="well-defined">Well-Defined</h3> |
| 78 <p>The following are traditionally undefined behavior in C/C++ but are well |
| 79 defined at the <em>pexe</em> level:</p> |
| 80 <ul class="small-gap"> |
| 81 <li>Dynamic initialization order dependencies: the order is deterministic |
| 82 in the <em>pexe</em>.</li> |
| 83 <li>Bool which isn’t <code>0</code>/<code>1</code>: the bitcode instructio
n sequence is |
| 84 deterministic in the <em>pexe</em>.</li> |
| 85 <li>Out-of-range <code>enum</code> value: the backing integer type and bitcode |
| 86 instruction sequence is deterministic in the <em>pexe</em>.</li> |
| 87 <li>Aggressive optimizations based on type-based alias analysis: TBAA |
| 88 optimizations are done before stable bitcode is generated and their |
| 89 metadata is stripped from the <em>pexe</em>; behavior is therefore |
| 90 deterministic in the <em>pexe</em>.</li> |
| 91 <li>Operator and subexpression evaluation order in the same expression |
| 92 (e.g. function parameter passing, or pre-increment): the order is |
| 93 defined in the <em>pexe</em>.</li> |
| 94 <li>Signed integer overflow: two’s complement integer arithmetic is |
| 95 assumed.</li> |
| 96 <li>Atomic access to a non-atomic memory location (not declared as |
| 97 <code>std::atomic</code>): atomics and <code>volatile</code> variables all lower
to the |
| 98 same compatible intrinsics or external functions; the behavior is |
| 99 therefore deterministic in the <em>pexe</em> (see <a class="reference internal"
href="/native-client/reference/pnacl-c-cpp-language-support.html#memory-model-an
d-atomics"><em>Memory Model and |
| 100 Atomics</em></a>).</li> |
| 101 <li>Integer divide by zero: always raises a fault (through hardware on |
| 102 x86, and through integer divide emulation routine or explicit checks |
| 103 on ARM).</li> |
| 104 </ul> |
| 105 </section><section id="not-well-defined"> |
| 106 <h3 id="not-well-defined">Not Well-Defined</h3> |
| 107 <p>The following are traditionally undefined behavior in C/C++ which also |
| 108 exhibit undefined behavior at the <em>pexe</em> level. Some are easier to fix |
| 109 than others.</p> |
| 110 <section id="potentially-fixable"> |
| 111 <h4 id="potentially-fixable">Potentially Fixable</h4> |
| 112 <ul class="small-gap"> |
| 113 <li><p class="first">Shift by greater-than-or-equal to left-hand-side’s bi
t-width or |
| 114 negative (see <a class="reference external" href="https://code.google.com/p/nati
veclient/issues/detail?id=3604">bug 3604</a>).</p> |
| 115 <ul class="small-gap"> |
| 116 <li>Some of the behavior will be specified in the <em>pexe</em> depending on |
| 117 constant propagation and integer type of variables.</li> |
| 118 <li>There is still some architecture-specific behavior.</li> |
| 119 <li>PNaCl could force-mask the right-hand-side to <cite>bitwidth-1</cite>, which |
| 120 could become a no-op on some architectures while ensuring all |
| 121 architectures behave similarly. Regular optimizations could also be |
| 122 applied, removing redundant masks.</li> |
| 123 </ul> |
| 124 </li> |
| 125 <li><p class="first">Using a virtual pointer of the wrong type, or of an unalloc
ated |
| 126 object.</p> |
| 127 <ul class="small-gap"> |
| 128 <li>Will produce wrong results which will depend on what data is treated |
| 129 as a <cite>vftable</cite>.</li> |
| 130 <li>PNaCl could add runtime checks for this, and elide them when types |
| 131 are provably correct (see this CFI <a class="reference external" href="https://c
ode.google.com/p/nativeclient/issues/detail?id=3786">bug 3786</a>).</li> |
| 132 </ul> |
| 133 </li> |
| 134 <li><p class="first">Some unaligned load/store (see <a class="reference external
" href="https://code.google.com/p/nativeclient/issues/detail?id=3445">bug 3445</
a>).</p> |
| 135 <ul class="small-gap"> |
| 136 <li>Could force everything to <cite>align 1</cite>; performance cost should be |
| 137 measured.</li> |
| 138 <li>The frontend could also be more pessimistic when it sees dubious |
| 139 casts.</li> |
| 140 </ul> |
| 141 </li> |
| 142 <li>Some values can be marked as <code>undef</code> (see <a class="reference ext
ernal" href="https://code.google.com/p/nativeclient/issues/detail?id=3796">bug 3
796</a>).</li> |
| 143 <li>Reaching end-of-value-returning-function without returning a value: |
| 144 reduces to <code>ret i32 undef</code> in bitcode. This is mostly-defined, but |
| 145 could be improved (see <a class="reference external" href="https://code.google.c
om/p/nativeclient/issues/detail?id=3796">bug 3796</a>).</li> |
| 146 <li><p class="first">Reaching “unreachable” code.</p> |
| 147 <ul class="small-gap"> |
| 148 <li>LLVM provides an IR instruction called “unreachable” whose effect |
| 149 will be undefined. PNaCl could change this to always trap, as the |
| 150 <code>llvm.trap</code> intrinsic does.</li> |
| 151 </ul> |
| 152 </li> |
| 153 <li>Zero or negative-sized variable-length array (and <code>alloca</code>) aren&
#8217;t |
| 154 defined behavior. PNaCl’s frontend or the translator could insert |
| 155 checks with <code>-fsanitize=vla-bound</code>.</li> |
| 156 </ul> |
| 157 </section><section id="floating-point"> |
| 158 <span id="undefined-behavior-fp"></span><h4 id="floating-point"><span id="undefi
ned-behavior-fp"></span>Floating-Point</h4> |
| 159 <p>PNaCl offers a IEEE-754 implementation which is as correct as the |
| 160 underlying hardware allows, with a few limitations. These are a few |
| 161 sources of undefined behavior which are believed to be fixable:</p> |
| 162 <ul class="small-gap"> |
| 163 <li>Float cast overflow is currently undefined.</li> |
| 164 <li>Float divide by zero is currently undefined.</li> |
| 165 <li>The default denormal behavior is currently unspecified, which isn’t |
| 166 IEEE-754 compliant (denormals must be supported in IEEE-754). PNaCl |
| 167 could mandate flush-to-zero, and may give an API to enable denormals |
| 168 in a future release. The latter is problematic for SIMD and |
| 169 vectorization support, where some platforms do not support denormal |
| 170 SIMD operations.</li> |
| 171 <li><code>NaN</code> values are currently not guaranteed to be canonical; see <a
class="reference external" href="https://code.google.com/p/nativeclient/issues/
detail?id=3536">bug |
| 172 3536</a>.</li> |
| 173 <li>Passing <code>NaN</code> to STL functions (the math is defined, but the |
| 174 function implementation isn’t, e.g. <code>std::min</code> and <code>std::m
ax</code>), is |
| 175 well-defined in the <em>pexe</em>.</li> |
| 176 </ul> |
| 177 </section><section id="hard-to-fix"> |
| 178 <h4 id="hard-to-fix">Hard to Fix</h4> |
| 179 <ul class="small-gap"> |
| 180 <li><p class="first">Null pointer/reference has behavior determined by the NaCl
sandbox:</p> |
| 181 <ul class="small-gap"> |
| 182 <li>Raises a segmentation fault in the bottom <code>64KiB</code> bytes on all |
| 183 platforms, and on some sandboxes there are further non-writable |
| 184 pages after the initial <code>64KiB</code>.</li> |
| 185 <li>Negative offsets aren’t handled consistently on all platforms: |
| 186 x86-64 and ARM will wrap around to the stack (because they mask the |
| 187 address), whereas x86-32 will fault (because of segmentation).</li> |
| 188 </ul> |
| 189 </li> |
| 190 <li><p class="first">Accessing uninitialized/free’d memory (including out-
of-bounds array |
| 191 access):</p> |
| 192 <ul class="small-gap"> |
| 193 <li>Might cause a segmentation fault or not, depending on where memory |
| 194 is allocated and how it gets reclaimed.</li> |
| 195 <li>Added complexity because of the NaCl sandboxing: some of the |
| 196 load/stores might be forced back into sandbox range, or eliminated |
| 197 entirely if they fall out of the sandbox.</li> |
| 198 </ul> |
| 199 </li> |
| 200 <li><p class="first">Executing non-program data (jumping to an address obtained
from a |
| 201 non-function pointer is undefined, can only do <code>void(*)()</code> to |
| 202 <code>intptr_t</code> to <code>void(*)()</code>).</p> |
| 203 <ul class="small-gap"> |
| 204 <li>Just-In-Time code generation is supported by NaCl, but is not |
| 205 currently supported by PNaCl. It is currently not possible to mark |
| 206 code as executable.</li> |
| 207 <li>Offering full JIT capabilities would reduce PNaCl’s ability to |
| 208 change the sandboxing model. It would also require a “jump to JIT |
| 209 code” syscall (to guarantee a calling convention), and means that |
| 210 JITs aren’t portable.</li> |
| 211 <li>PNaCl could offer “portable” JIT capabilities where the code han
ds |
| 212 PNaCl some form of LLVM IR, which PNaCl then JIT-compiles.</li> |
| 213 </ul> |
| 214 </li> |
| 215 <li>Out-of-scope variable usage: will produce unknown data, mostly |
| 216 dependent on stack and memory allocation.</li> |
| 217 <li>Data races: any two operations that conflict (target overlapping |
| 218 memory), at least one of which is a store or atomic read-modify-write, |
| 219 and at least one of which is not atomic: this will be very dependent |
| 220 on processor and execution sequence, see <a class="reference internal" href="/na
tive-client/reference/pnacl-c-cpp-language-support.html#memory-model-and-atomics
"><em>Memory Model and |
| 221 Atomics</em></a>.</li> |
| 222 </ul> |
| 223 </section></section></section></section> |
| 224 |
| 225 {{/partials.standard_nacl_article}} |
| OLD | NEW |
|---|
Chromium Code Reviews
Issue 164413005:
PNaCl documentation: add undefined behavior (Closed)
Base URL: svn://svn.chromium.org/chrome/trunk/src