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

[Peter Collingbourne]

================
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.
+
----------------
jfb wrote:
> 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).
Done

================
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.
+
----------------
jfb wrote:
> 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!
Yes. I now mention this in the limitations section.

================
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.
----------------
jfb wrote:
> Format ``dlopen()``
Done

================
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.
+
----------------
jfb wrote:
> What implications does this attribute have on the overall system's security?
Added a relevant paragraph.

================
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.
+
----------------
jfb wrote:
> What happens when calling ``__builtin_frame_address`` with SafeStack?
I believe it will return a pointer to the safe stack. I've added some stuff to the Limitations section about this.

http://reviews.llvm.org/D6095

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/