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

[Kostya Serebryany]

On Sat, Nov 15, 2014 at 4:53 AM, Volodymyr Kuznetsov <vova.kuznetsov at epfl.ch
> wrote:

> Hi Kostya,
>
> >On Wed, Nov 12, 2014 at 2:50 AM, Volodymyr Kuznetsov <vova.kuznetsov at
> epfl.ch
> >> wrote:
> >
> >> Dear LLVM developers,
> >>
> >> We've applied the feedback we received on Phabricator on the SafeStack
> >> patches,
> >>
> >
> >Did you investigate the possibility of moving the transformation from
> >codegen to the LLVM level, i.e. the same level where asan/msan/tsan/dfsan
> >work?
> >I understand that it's a lot of work, but it will pay off with greater
> >portability and maintainability later.
>
> We're currently considering doing something in-between. We could place
> the SafeStack pass in lib/Transformation/Instrumentation, so that it
> can be easily invoked with opt and operate on IR, but still schedule
> the pass during code generation by default.
>
> The latter is especially important when using LTO: running SafeStack
> before LTO would both impair the effectiveness of LTO (e.g., by
> breaking alias analysis, mem2reg, etc), and prevent SafeStack from
> taking advantage of the extra information obtained during LTO (e.g.,
> LTO can remove some pointer uses through inlining and DCE, etc.). Even
> without LTO, some of the passes scheduled during code generation (in
> addPassesToGenerateCode) could affect the security and the performance
> of the generated code as well.
>




>
> Do you think moving the pass to lib/Transform/Instrumentation but
> scheduling it during code generation would make sense ? If so, we'll
> do that and change the safestack tests to use opt instead of llc.
>

I think this should be doable, however I am not an expert in the pass
manager and LTO, hopefully someone else can comment.
Nick?


>
> >Also, did you reply to my comments about reusing compiler-rt code from
> >sanitizer_common?
> >I see lots of places in lib/safestack where you duplicate existing
> >functionality from lib/sanitizer_common
>
> Yes, we would like to use some of the functions from sanitizer_common
> (e.g., internal_mmap/munmap and some pthread-related functions), but
> linking the entire sanitizer_common just for that might be an
> overkill. E.g., it can make small programs like coreutils up to 3x
> larger, and it requires compiling with -pthread. Perhaps we can move
> those functions to separate files in sanitizer_common and make them
> usable independently from the rest of sanitizer_common?
>

Clearly.
samsonov@ would know more about splitting sanitizer_common into pieces,
he has already done similar things.

--kcc


>
> - Vova
> _______________________________________________
> 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/20141117/c7d1ae73/attachment.html>