Skip to content

Latest commit

 

History

History
52 lines (46 loc) · 2.85 KB

Nondeterminism.md

File metadata and controls

52 lines (46 loc) · 2.85 KB
Raw

Nondeterminism in WebAssembly

WebAssembly is a portable sandboxed platform with limited, local, nondeterminism.

  • Limited: nondeterministic execution can only occur in a small number of well-defined cases (described below) and, in those cases, the implementation may select from a limited set of possible behaviors.
  • Local: when nondeterministic execution occurs, the effect is local, there is no "spooky action at a distance".

The rationale document details why WebAssembly is designed as detailed in this document.

The limited, local, nondeterministic model implies:

  • Applications can't access data outside the sandbox without going through appropriate APIs, or otherwise escape the sandbox.
  • WebAssembly always maintains valid, trusted callstacks; stray pointer writes cannot corrupt return addresses or spilled variables on the stack.
  • Calls and branches always have valid destinations ensuring Control Flow Integrity.
  • WebAssembly has no nasal demons.

The following is a list of the places where the WebAssembly specification currently admits nondeterminism:

  • When threads are added as a feature, even without shared memory, nondeterminism will be visible through the global sequence of API calls. With shared memory, the result of load operations is nondeterministic.
  • The value returned by page_size is system-dependent. The arguments to the grow_memory and other future memory management builtins are required to be multiples of page_size.
  • NaN bit patterns in floating point operations and conversions
  • Fixed-width SIMD may want some flexibility
    • In SIMD.js, floating point values may or may not have subnormals flushed to zero.
    • In SIMD.js, operations ending in "Approximation" return approximations that may vary between platforms.
  • Environment-dependent resource limits may be exhausted. A few examples:
    • Memory allocation may fail.
    • Program stack may get exhausted (e.g., because function call depth is too big, or functions have too many locals, or infinite recursion). Note that this stack isn't located in the program-accessible linear memory.
    • Resources such as handles may get exhausted.

Users of C, C++, and similar languages should be aware that operations which have defined or constrained behavior in WebAssembly itself may nonetheless still have undefined behavior at the source code level.