native_client_sdk/src/doc/reference/pnacl-undefined-behavior.rst

.. include:: /migration/deprecation.inc

========================
PNaCl Undefined Behavior
========================

.. contents::
   :local:
   :backlinks: none
   :depth: 3

.. _undefined_behavior:

Overview
========

C and C++ undefined behavior allows efficient mapping of the source
language onto hardware, but leads to different behavior on different
platforms.

PNaCl exposes undefined behavior in the following ways:

* The Clang frontend and optimizations that occur on the developer's
  machine determine what behavior will occur, and it will be specified
  deterministically in the *pexe*. All targets will observe the same
  behavior. In some cases, recompiling with a newer PNaCl SDK version
  will either:

  * Reliably emit the same behavior in the resulting *pexe*.
  * Change the behavior that gets specified in the *pexe*.

* The behavior specified in the *pexe* relies on PNaCl's bitcode,
  runtime or CPU architecture vagaries.

  * In some cases, the behavior using the same PNaCl translator version
    on different architectures will produce different behavior.
  * Sometimes runtime parameters determine the behavior, e.g. memory
    allocation determines which out-of-bounds accesses crash versus
    returning garbage.
  * In some cases, different versions of the PNaCl translator
    (i.e. after a Chrome update) will compile the code differently and
    cause different behavior.
  * In some cases, the same versions of the PNaCl translator, on the
    same architecture, will generate a different *nexe* for
    defense-in-depth purposes, but may cause code that reads invalid
    stack values or code sections on the heap to observe these
    randomizations.

Specification
=============

PNaCl's goal is that a single *pexe* should work reliably in the same
manner on all architectures, irrespective of runtime parameters and
through Chrome updates. This goal is unfortunately not attainable; PNaCl
therefore specifies as much as it can and outlines areas for
improvement.

One interesting solution is to offer good support for LLVM's sanitizer
tools (including `UBSan
<http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation>`_)
at development time, so that developers can test their code against
undefined behavior. Shipping code would then still get good performance,
and diverging behavior would be rare.

Note that none of these issues are vulnerabilities in PNaCl and Chrome:
the NaCl sandboxing still constrains the code through Software Fault
Isolation.

Behavior in PNaCl Bitcode
=========================

Well-Defined
------------

The following are traditionally undefined behavior in C/C++ but are well
defined at the *pexe* level:

* Dynamic initialization order dependencies: the order is deterministic
  in the *pexe*.
* Bool which isn't ``0``/``1``: the bitcode instruction sequence is
  deterministic in the *pexe*.
* Out-of-range ``enum`` value: the backing integer type and bitcode
  instruction sequence is deterministic in the *pexe*.
* Aggressive optimizations based on type-based alias analysis: TBAA
  optimizations are done before stable bitcode is generated and their
  metadata is stripped from the *pexe*; behavior is therefore
  deterministic in the *pexe*.
* Operator and subexpression evaluation order in the same expression
  (e.g. function parameter passing, or pre-increment): the order is
  defined in the *pexe*.
* Signed integer overflow: two's complement integer arithmetic is
  assumed.
* Atomic access to a non-atomic memory location (not declared as
  ``std::atomic``): atomics and ``volatile`` variables all lower to the
  same compatible intrinsics or external functions; the behavior is
  therefore deterministic in the *pexe* (see :ref:`Memory Model and
  Atomics <memory_model_and_atomics>`).
* Integer divide by zero: always raises a fault (through hardware on
  x86, and through integer divide emulation routine or explicit checks
  on ARM).

Not Well-Defined
----------------

The following are traditionally undefined behavior in C/C++ which also
exhibit undefined behavior at the *pexe* level. Some are easier to fix
than others.

Potentially Fixable
^^^^^^^^^^^^^^^^^^^

* Shift by greater-than-or-equal to left-hand-side's bit-width or
  negative (see `bug 3604
  <https://code.google.com/p/nativeclient/issues/detail?id=3604>`_).

  * Some of the behavior will be specified in the *pexe* depending on
    constant propagation and integer type of variables.
  * There is still some architecture-specific behavior.
  * PNaCl could force-mask the right-hand-side to `bitwidth-1`, which
    could become a no-op on some architectures while ensuring all
    architectures behave similarly. Regular optimizations could also be
    applied, removing redundant masks.

* Using a virtual pointer of the wrong type, or of an unallocated
  object.

  * Will produce wrong results which will depend on what data is treated
    as a `vftable`.
  * PNaCl could add runtime checks for this, and elide them when types
    are provably correct (see this CFI `bug 3786
    <https://code.google.com/p/nativeclient/issues/detail?id=3786>`_).

* Some unaligned load/store (see `bug 3445
  <https://code.google.com/p/nativeclient/issues/detail?id=3445>`_).

  * Could force everything to `align 1`; performance cost should be
    measured.
  * The frontend could also be more pessimistic when it sees dubious
    casts.

* Some values can be marked as ``undef`` (see `bug 3796
  <https://code.google.com/p/nativeclient/issues/detail?id=3796>`_).

* Reaching end-of-value-returning-function without returning a value:
  reduces to ``ret i32 undef`` in bitcode. This is mostly-defined, but
  could be improved (see `bug 3796
  <https://code.google.com/p/nativeclient/issues/detail?id=3796>`_).

* Reaching “unreachable” code.

  * LLVM provides an IR instruction called “unreachable” whose effect
    will be undefined.  PNaCl could change this to always trap, as the
    ``llvm.trap`` intrinsic does.

* Zero or negative-sized variable-length array (and ``alloca``) aren't
  defined behavior. PNaCl's frontend or the translator could insert
  checks with ``-fsanitize=vla-bound``.

.. _undefined_behavior_fp:

Floating-Point
^^^^^^^^^^^^^^

PNaCl offers a IEEE-754 implementation which is as correct as the
underlying hardware allows, with a few limitations. These are a few
sources of undefined behavior which are believed to be fixable:

* Float cast overflow is currently undefined.
* Float divide by zero is currently undefined.
* The default denormal behavior is currently unspecified, which isn't
  IEEE-754 compliant (denormals must be supported in IEEE-754). PNaCl
  could mandate flush-to-zero, and may give an API to enable denormals
  in a future release. The latter is problematic for SIMD and
  vectorization support, where some platforms do not support denormal
  SIMD operations.
* ``NaN`` values are currently not guaranteed to be canonical; see `bug
  3536 <https://code.google.com/p/nativeclient/issues/detail?id=3536>`_.
* Passing ``NaN`` to STL functions (the math is defined, but the
  function implementation isn't, e.g. ``std::min`` and ``std::max``), is
  well-defined in the *pexe*.

SIMD Vectors
^^^^^^^^^^^^

SIMD vector instructions aren't part of the C/C++ standards and as such
their behavior isn't specified at all in C/C++; it is usually left up to
the target architecture to specify behavior. Portable Native Client
instead exposed :ref:`Portable SIMD Vectors <portable_simd_vectors>` and
offers the same guarantees on these vectors as the guarantees offered by
the contained elements. Of notable interest amongst these guarantees are
those of alignment for load/store instructions on vectors: they have the
same alignment restriction as the contained elements.

Hard to Fix
^^^^^^^^^^^

* Null pointer/reference has behavior determined by the NaCl sandbox:

  * Raises a segmentation fault in the bottom ``64KiB`` bytes on all
    platforms, and on some sandboxes there are further non-writable
    pages after the initial ``64KiB``.
  * Negative offsets aren't handled consistently on all platforms:
    x86-64 and ARM will wrap around to the stack (because they mask the
    address), whereas x86-32 will fault (because of segmentation).

* Accessing uninitialized/free'd memory (including out-of-bounds array
  access):

  * Might cause a segmentation fault or not, depending on where memory
    is allocated and how it gets reclaimed.
  * Added complexity because of the NaCl sandboxing: some of the
    load/stores might be forced back into sandbox range, or eliminated
    entirely if they fall out of the sandbox.

* Executing non-program data (jumping to an address obtained from a
  non-function pointer is undefined, can only do ``void(*)()`` to
  ``intptr_t`` to ``void(*)()``).

  * Just-In-Time code generation is supported by NaCl, but is not
    currently supported by PNaCl. It is currently not possible to mark
    code as executable.
  * Offering full JIT capabilities would reduce PNaCl's ability to
    change the sandboxing model. It would also require a "jump to JIT
    code" syscall (to guarantee a calling convention), and means that
    JITs aren't portable.
  * PNaCl could offer "portable" JIT capabilities where the code hands
    PNaCl some form of LLVM IR, which PNaCl then JIT-compiles.

* Out-of-scope variable usage: will produce unknown data, mostly
  dependent on stack and memory allocation.
* Data races: any two operations that conflict (target overlapping
  memory), at least one of which is a store or atomic read-modify-write,
  and at least one of which is not atomic: this will be very dependent
  on processor and execution sequence, see :ref:`Memory Model and
  Atomics <memory_model_and_atomics>`.