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

[Nick Lewycky]

On 17 November 2014 11:28, Kostya Serebryany <kcc at google.com> wrote:

> +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)
>

I haven't read the paper or patch yet, but reading the thread it does sound
like we should put it into an IR pass if possible. We'll have the
flexibility to schedule when it runs; I agree in the LTO case it's
important not to run it until right before codegenprepare, but we can sort
that out later (we want the pass pipeline for compiles in LTO builds to be
different from the pipeline for regular compiles producing object files,
but it isn't yet).

There is some access to TargetMachine from the IR passes, but instead of
extending that, could we add new intrinsics? There already is
@llvm.returnaddress and @llvm.frameaddress. Do you want @llvm.stackaddress?
or would @llvm.frameaddress suffice? And while we could add
@llvm.stackalignment, would it work to deduce minimum alignment from the
alloca statements present?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141118/63b41f33/attachment.html>