xref: /aosp_15_r20/external/clang/docs/SafeStack.rst (revision 67e74705e28f6214e480b399dd47ea732279e315)

=========
SafeStack
=========

.. contents::
   :local:

Introduction
============

SafeStack is an instrumentation pass that protects programs against attacks
based on stack buffer overflows, without introducing any measurable performance
overhead. It works by separating the program stack into two distinct regions:
the safe stack and the unsafe stack. The safe stack stores return addresses,
register spills, and local variables that are always accessed in a safe way,
while the unsafe stack stores everything else. This separation ensures that
buffer overflows on the unsafe stack cannot be used to overwrite anything
on the safe stack.

SafeStack is a part of the `Code-Pointer Integrity (CPI) Project
<http://dslab.epfl.ch/proj/cpi/>`_.

Performance
-----------

The performance overhead of the SafeStack instrumentation is less than 0.1% on
average across a variety of benchmarks (see the `Code-Pointer Integrity
<http://dslab.epfl.ch/pubs/cpi.pdf>`__ paper for details). This is mainly
because most small functions do not have any variables that require the unsafe
stack and, hence, do not need unsafe stack frames to be created. The cost of
creating unsafe stack frames for large functions is amortized by the cost of
executing the function.

In some cases, SafeStack actually improves the performance. Objects that end up
being moved to the unsafe stack are usually large arrays or variables that are
used through multiple stack frames. Moving such objects away from the safe
stack increases the locality of frequently accessed values on the stack, such
as register spills, return addresses, and small local variables.

Compatibility
-------------

Most programs, static libraries, or individual files can be compiled
with SafeStack as is. SafeStack requires basic runtime support, which, on most
platforms, is implemented as a compiler-rt library that is automatically linked
in when the program is compiled with SafeStack.

Linking a DSO with SafeStack is not currently supported.

Known compatibility limitations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Certain code that relies on low-level stack manipulations requires adaption to
work with SafeStack. One example is mark-and-sweep garbage collection
implementations for C/C++ (e.g., Oilpan in chromium/blink), which must be
changed to look for the live pointers on both safe and unsafe stacks.

SafeStack supports linking statically modules that are compiled with and
without SafeStack. An executable compiled with SafeStack can load dynamic
libraries that are not compiled with SafeStack. At the moment, compiling
dynamic libraries with SafeStack is not supported.

Signal handlers that use ``sigaltstack()`` must not use the unsafe stack (see
``__attribute__((no_sanitize("safe-stack")))`` below).

Programs that use APIs from ``ucontext.h`` are not supported yet.

Security
--------

SafeStack protects return addresses, spilled registers and local variables that
are always accessed in a safe way by separating them in a dedicated safe stack
region. The safe stack is automatically protected against stack-based buffer
overflows, since it is disjoint from the unsafe stack in memory, and it itself
is always accessed in a safe way. In the current implementation, the safe stack
is protected against arbitrary memory write vulnerabilities though
randomization and information hiding: the safe stack is allocated at a random
address and the instrumentation ensures that no pointers to the safe stack are
ever stored outside of the safe stack itself (see limitations below).

Known security limitations
~~~~~~~~~~~~~~~~~~~~~~~~~~

A complete protection against control-flow hijack attacks requires combining
SafeStack with another mechanism that enforces the integrity of code pointers
that are stored on the heap or the unsafe stack, such as `CPI
<http://dslab.epfl.ch/proj/cpi/>`_, or a forward-edge control flow integrity
mechanism that enforces correct calling conventions at indirect call sites,
such as `IFCC <http://research.google.com/pubs/archive/42808.pdf>`_ with arity
checks. Clang has control-flow integrity protection scheme for :doc:`C++ virtual
calls <ControlFlowIntegrity>`, but not non-virtual indirect calls. With
SafeStack alone, an attacker can overwrite a function pointer on the heap or
the unsafe stack and cause a program to call arbitrary location, which in turn
might enable stack pivoting and return-oriented programming.

In its current implementation, SafeStack provides precise protection against
stack-based buffer overflows, but protection against arbitrary memory write
vulnerabilities is probabilistic and relies on randomization and information
hiding. The randomization is currently based on system-enforced ASLR and shares
its known security limitations. The safe stack pointer hiding is not perfect
yet either: system library functions such as ``swapcontext``, exception
handling mechanisms, intrinsics such as ``__builtin_frame_address``, or
low-level bugs in runtime support could leak the safe stack pointer. In the
future, such leaks could be detected by static or dynamic analysis tools and
prevented by adjusting such functions to either encrypt the stack pointer when
storing it in the heap (as already done e.g., by ``setjmp``/``longjmp``
implementation in glibc), or store it in a safe region instead.

The `CPI paper <http://dslab.epfl.ch/pubs/cpi.pdf>`_ describes two alternative,
stronger safe stack protection mechanisms, that rely on software fault
isolation, or hardware segmentation (as available on x86-32 and some x86-64
CPUs).

At the moment, SafeStack assumes that the compiler's implementation is correct.
This has not been verified except through manual code inspection, and could
always regress in the future. It's therefore desirable to have a separate
static or dynamic binary verification tool that would check the correctness of
the SafeStack instrumentation in final binaries.

Usage
=====

To enable SafeStack, just pass ``-fsanitize=safe-stack`` flag to both compile
and link command lines.

Supported Platforms
-------------------

SafeStack was tested on Linux, FreeBSD and MacOSX.

Low-level API
-------------

``__has_feature(safe_stack)``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In some rare cases one may need to execute different code depending on
whether SafeStack is enabled. The macro ``__has_feature(safe_stack)`` can
be used for this purpose.

.. code-block:: c

    #if __has_feature(safe_stack)
    // code that builds only under SafeStack
    #endif

``__attribute__((no_sanitize("safe-stack")))``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Use ``__attribute__((no_sanitize("safe-stack")))`` on a function declaration
to specify that the safe stack instrumentation should not be applied to that
function, even if enabled globally (see ``-fsanitize=safe-stack`` flag). This
attribute may be required for functions that make assumptions about the
exact layout of their stack frames.

All local variables in functions with this attribute will be stored on the safe
stack. The safe stack remains unprotected against memory errors when accessing
these variables, so extra care must be taken to manually ensure that all such
accesses are safe. Furthermore, the addresses of such local variables should
never be stored on the heap, as it would leak the location of the SafeStack.

``__builtin___get_unsafe_stack_ptr()``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This builtin function returns current unsafe stack pointer of the current
thread.

``__builtin___get_unsafe_stack_start()``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This builtin function returns a pointer to the start of the unsafe stack of the
current thread.

Design
======

Please refer to the `Code-Pointer Integrity <http://dslab.epfl.ch/proj/cpi/>`__
project page for more information about the design of the SafeStack and its
related technologies.

setjmp and exception handling
-----------------------------

The `OSDI'14 paper <http://dslab.epfl.ch/pubs/cpi.pdf>`_ mentions that
on Linux the instrumentation pass finds calls to setjmp or functions that
may throw an exception, and inserts required instrumentation at their call
sites. Specifically, the instrumentation pass saves the shadow stack pointer
on the safe stack before the call site, and restores it either after the
call to setjmp or after an exception has been caught. This is implemented
in the function ``SafeStack::createStackRestorePoints``.

Publications
------------

`Code-Pointer Integrity <http://dslab.epfl.ch/pubs/cpi.pdf>`__.
Volodymyr Kuznetsov, Laszlo Szekeres, Mathias Payer, George Candea, R. Sekar, Dawn Song.
USENIX Symposium on Operating Systems Design and Implementation
(`OSDI <https://www.usenix.org/conference/osdi14>`_), Broomfield, CO, October 2014