[PATCH] D18846: [safestack] Add canary to unsafe stack frames

[Evgeniy Stepanov via llvm-commits]

eugenis added a comment.

> > Also, there may be no unsafe stack frame at all, then there would be no need for the guard at all. SafeStack is currently smarter about this than StackProtector; it uses SCEV to prove that allocas can never overflow.

> 

> 

> What if the source code does overflow? Does SafeStack just fails to build (seems unlikely?), or SSP still needs to be inserted?


The unsafe frame consists of allocas that SafeStack could _not_ prove to not overflow. SSP is only needed such allocas exist.

I've looked into reducing code duplication, but it seems to make things a lot more complex. Basically, we could allow StackProtector to insert the cookie and then just move it to the unsafe stack along with other allocas, making sure that it ends up at the bottom of the frame. The problem is, StackProtector does not know if the cookie is needed or not - it needs to ask SafeStack for that. I've considered splitting SafeStack into an analysis pass that would answer this question, and an instrumentation pass, but that seems to add a lot of complexity and a few non-obvious inter-pass dependencies.

I'm inclined to commit this as is, and maybe revisit this point if code duplication becomes a problem.


Repository:
  rL LLVM

http://reviews.llvm.org/D18846