[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack

[Volodymyr Kuznetsov]

Hi David,

Thanks a lot for your quick reply and your interest in our technique! I've
just uploaded the three patches to Phabricator:
http://reviews.llvm.org/D6094, http://reviews.llvm.org/D6095 and
http://reviews.llvm.org/D6096 .

We will prepare the patches for the 3.5 branch as well (it should be fairly
straightforward, as most changes are well isolated) and send them to you
tomorrow. We would also be glad to share our changes to the FreeBSD libc
that integrate the safe stack runtime in a more direct and clean way than
if linked as a compiler-rt library.

- Vova

On Mon, Nov 3, 2014 at 5:40 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:

> Hi Volodymyr,
>
> I enjoyed the paper, and we're very interested in deploying this technique
> on FreeBSD.  Would you mind putting the patches on Phabricator (
> http://reviews.llvm.org) and adding me as a reviewer?
>
> David
>
> P.S. If you have patches against the LLVM 3.5 release, we'd be interested
> in importing them into copy of LLVM in the FreeBSD tree, otherwise we'll
> grab them as part of the next LLVM release.
>
> On 3 Nov 2014, at 16:05, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch>
> wrote:
>
> > Dear LLVM developers,
> >
> > Our team has developed an LLVM-based protection mechanism that (i)
> prevents control-flow hijack attacks enabled by memory corruption errors
> and (ii) has very low performance overhead. We would like to contribute the
> implementation to LLVM. We presented this work at the OSDI 2014 conference,
> at several software companies, and several US universities. We received
> positive feedback, and so we've open-sourced our prototype available for
> download from our project website (http://levee.epfl.ch).
> >
> > There are three components (safe stack, CPS, and CPI), and each can be
> used individually. Our most stable part is the safe stack instrumentation,
> 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. A detailed description of the
> individual components is available in our OSDI paper on code-pointer
> integrity (http://dslab.epfl.ch/pubs/cpi.pdf).
> >
> > The overhead of our implementation of the safe stack is very close to
> zero (0.01% on the Phoronix benchmarks and 0.03% on SPEC2006 CPU on
> average). 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.
> >
> > We attach our implementation of the safe stack as three patches against
> current SVN HEAD of LLVM (r221153), clang (r221154) and compiler-rt
> (r220991). The same changes are also available on
> https://github.com/cpi-llvm in the safestack-r221153 branches of
> corresponding repositories. 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 -fsafe-stack and -fno-safe-stack options to clang to control safe
> stack usage (the safe stack is disabled by default).
> > -- Add __attribute__((no_safe_stack)) attribute to clang that can be
> used to disable the safe stack for individual functions even when enabled
> globally.
> > -- Add basic runtime support for the safe stack to compiler-rt. The
> runtime manages unsafe stack allocation/deallocation for each thread.
> > -- Add unit tests for the safe stack.
> >
> > 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. FYI
> here is the abstract of the paper:
> >
> > << Systems code is often written in low-level languages like C/C++,
> which offer many benefits but also delegate memory management to
> programmers. This invites memory safety bugs that attackers can exploit to
> divert control flow and compromise the system. Deployed defense mechanisms
> (e.g., ASLR, DEP) are incomplete, and stronger defense mechanisms (e.g.,
> CFI) often have high overhead and limited guarantees.
> >
> > We introduce code-pointer integrity (CPI), a new design point that
> guarantees the integrity of all code pointers in a program (e.g., function
> pointers, saved return addresses) and thereby prevents all control-flow
> hijack attacks, including return-oriented programming. We also introduce
> code-pointer separation (CPS), a relaxation of CPI with better performance
> properties. CPI and CPS offer substantially better security-to-overhead
> ratios than the state of the art, they are practical (we protect a complete
> FreeBSD system and over 100 packages like apache and postgresql), effective
> (prevent all attacks in the RIPE benchmark), and efficient: on SPEC
> CPU2006, CPS averages 1.2% overhead for C and 1.9% for C/C++, while CPI’s
> overhead is 2.9% for C and 8.4% for C/C++. >>
> >
> > (This is joint work with V. Kuznetsov, L. Szekeres, M. Payer, G. Candea,
> R. Sekar, and D. Song)
> >
> > We look forward to your feedback and hope for a prompt merge into LLVM,
> to make the software built with clang more secure.
> >
> > - Volodymyr Kuznetsov & the CPI team
> >
> <safestack-llvm.diff><safestack-clang.diff><safestack-compiler-rt.diff>_______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/7f18f562/attachment.html>