[llvm] r239761 - Protection against stack-based memory corruption errors using SafeStack

[Tobias Grosser]

On 06/15/2015 11:07 PM, Peter Collingbourne wrote:
> Author: pcc
> Date: Mon Jun 15 16:07:11 2015
> New Revision: 239761
>
> URL: http://llvm.org/viewvc/llvm-project?rev=239761&view=rev
> Log:
> Protection against stack-based memory corruption errors using SafeStack
>
> This patch adds the safe stack instrumentation pass to LLVM, which separates
> the program stack into a safe stack, which stores return addresses, register
> spills, and local variables that are statically verified to be accessed
> in a safe way, and the unsafe stack, which stores everything else. Such
> separation makes it much harder for an attacker to corrupt objects on the
> safe stack, including function pointers stored in spilled registers and
> return addresses. You can find more information about the safe stack, as
> well as other parts of or control-flow hijack protection technique in our
> OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf)
> and our project website (http://levee.epfl.ch).
>
> The overhead of our implementation of the safe stack is very close to zero
> (0.01% on the Phoronix benchmarks). This is lower than the overhead of
> stack cookies, which are supported by LLVM and are commonly used today,
> yet the security guarantees of the safe stack are strictly stronger than
> stack cookies. In some cases, the safe stack improves performance due to
> better cache locality.
>
> Our current implementation of the safe stack is stable and robust, we
> used it to recompile multiple projects on Linux including Chromium, and
> we also recompiled the entire FreeBSD user-space system and more than 100
> packages. We ran unit tests on the FreeBSD system and many of the packages
> and observed no errors caused by the safe stack. The safe stack is also fully
> binary compatible with non-instrumented code and can be applied to parts of
> a program selectively.
>
> This patch is our implementation of the safe stack on top of LLVM. The
> patches make the following changes:
>
> - Add the safestack function attribute, similar to the ssp, sspstrong and
>    sspreq attributes.
>
> - Add the SafeStack instrumentation pass that applies the safe stack to all
>    functions that have the safestack attribute. This pass moves all unsafe local
>    variables to the unsafe stack with a separate stack pointer, whereas all
>    safe variables remain on the regular stack that is managed by LLVM as usual.
>
> - Invoke the pass as the last stage before code generation (at the same time
>    the existing cookie-based stack protector pass is invoked).
>
> - Add unit tests for the safe stack.
>
> Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
> Lab at EPFL; updates and upstreaming by myself.

Hi Peter,

after this patch I get compilation errors in my CUDA kernel extractor 
that say:

	Undefined reference to '__safestack_unsafe_stack_ptr' in ''

This seems to be the culprit:


> +  virtual bool doInitialization(Module &M) {
> +    DL = &M.getDataLayout();
> +
> +    StackPtrTy = Type::getInt8PtrTy(M.getContext());
> +    IntPtrTy = DL->getIntPtrType(M.getContext());
> +    Int32Ty = Type::getInt32Ty(M.getContext());
> +    Int8Ty = Type::getInt8Ty(M.getContext());
> +
> +    UnsafeStackPtr = getOrCreateUnsafeStackPtr(M);

We add the StackPtr Global even though not a single safestack attribute 
was added in the module. Besides adding unnecessary noise (a global 
without any use), this also breaks the execution on NVIDIA GPUs as they 
abort with the error above.

If I comment out the above line, my code starts working again.

Any chance, this attribute can just be added on demand?


Best,
Tobias