llvm dev - Nov 2014 - [LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack

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

Hi Kostya,

On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov <vova.kuznetsov at
epfl.ch>
wrote:
> 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 tried to move the SafeStack to lib/Transform/Instrumentation, but I
realized that the SafeStack pass depends on TargetMachine: it gets the
stack alignment from TargetFrameLowering and the location of the unsafe
stack pointer from TargetLowering. It seems that making TargetMachine
available in opt would require opt to depend on more things from CodeGen
than it normally should.

- Vova
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141117/81aa7c7d/attachment.html>

+nlewycky


On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <vova.kuznetsov at
epfl.ch
> wrote:
> Hi Kostya,
>
> On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov <
> vova.kuznetsov at epfl.ch> wrote:
> > 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 tried to move the SafeStack to lib/Transform/Instrumentation, but I
> realized that the SafeStack pass depends on TargetMachine: it gets the
> stack alignment from TargetFrameLowering and the location of the unsafe
> stack pointer from TargetLowering. It seems that making TargetMachine
> available in opt would require opt to depend on more things from CodeGen
> than it normally should.
>
Nick, please comment on TargetMachine in LLVM.
Can we get stack alignment and current stack pointer at the LLVM level,
before CodeGen (i.e. so that it works in opt, not in llc)

>
> - Vova
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141117/5351cbd8/attachment.html>

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>