[PATCH] Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute

JF Bastien jfb at chromium.org
Thu May 21 09:04:29 PDT 2015

The patch description mentions ``__attribute__((no_safe_stack))`` which isn't the name used anymore.

Comment at: docs/SafeStack.rst:18
@@ +17,3 @@
+buffer overflows on the unsafe stack cannot be used to overwrite anything
+on the safe stack, which includes return addresses.
It would be good to document the limitations that this approach has.

Off the top of my head:
* The safe stack is merely hidden from attackers by being somewhere in the address space. That's nice, but can be predictable even on 64-bit address spaces because not all the bits are addressable, multiple threads each have their stack, ...
* This approach doesn't prevent an attacker from "imbalancing" the safe stack by say having just one call, and doing two rets (thereby returning to an address that wasn't meant as a return address).

Comment at: docs/SafeStack.rst:51
@@ +50,3 @@
+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.
Does this have any security implications by making Oilpan spill the SafeStack address? I'm assuming that care must be taken not to do so!

Comment at: docs/SafeStack.rst:55
@@ +54,3 @@
+SafeStack, both statically and dynamically. One corner case that is not
+supported is using dlopen() to load a dynamic library that uses SafeStack into
+a program that is not compiled with SafeStack but uses threads.
Format ``dlopen()``

Comment at: docs/SafeStack.rst:97
@@ +96,3 @@
+attribute may be required for functions that make assumptions about the
+exact layout of their stack frames.
What implications does this attribute have on the overall system's security?

Comment at: docs/SafeStack.rst:109
@@ +108,3 @@
+This builtin function returns a pointer to the start of the unsafe stack of the
+current thread.
What happens when calling ``__builtin_frame_address`` with SafeStack?



More information about the cfe-commits mailing list