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

[Volodymyr Kuznetsov]

Hi Nick,

Thanks for your suggestions! Please find some replies and more questions
below.

On Wed Nov 19 2014 at 2:40:29 AM Nick Lewycky <nlewycky at google.com> wrote:

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

The SafeStack pass essentially picks some of the alloca instructions and
replaces them with allocations on the unsafe stack. Since the unsafe stack
frames are simpler then regular stack frames (e.g., they don't contain any
register spills) and LLVM doesn't know about the unsafe stack anyway, the
SafeStack pass is itself responsible for computing the layout of the unsafe
stack frames. This computation is pretty low-level and needs the concrete
value of the unsafe stack alignment, the intrinsic wouldn't suffice for
this purpose.


> And while we could add @llvm.stackalignment, would it work to deduce
> minimum alignment from the alloca statements present?
>

The stack alignment must be enforced inter-procedurally: each function
expects it to be at least given predefined function. Hence, analyzing local
alloca instruction won't be enough.

In principle, we could just make the alignment to be some constant large
value across all platforms, but that would impact performance. Getting the
actual stack alignment for the current platform makes much more sense.

There already is @llvm.returnaddress and @llvm.frameaddress. Do you want
> @llvm.stackaddress? or would @llvm.frameaddress suffice?
>

The unsafe stack uses it's own stack pointer, which is stored either in a
thread-local variable or in the thread control block data structure. This
is very platform dependent, so we added a function to TargetLowering which
determines this location for each platform, based on TargetMachine
(similarly to the existing getStackCookieLocation function, which is used
for analogous purpose by the existing StackProtector pass). Should we just
create the TargetMachine instance in opt (similarly to how it is created
during link-time optimizations) ?

Thanks!
- Vova
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141120/321ef206/attachment.html>