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

[Volodymyr Kuznetsov]

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.

>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?

- Vova