Update LLVM and add the safestack attribute to all generated functions.

[emberian]

LLVM recently landed: http://reviews.llvm.org/D6094. Clang's documentation on it. We should enable it on static libraries/executables, as the performance costs seem to be non-existent-to-negligible, and it extends defense-in-depth rather well.

cc #15179, as this effectively replaces stack canaries.

[emberian]

We'll need to upgrade our compiler-rt as well. We will probably need to add an attribute to allow functions or maybe even crates to opt-out of this treatment, as things such as signal handlers and the lowest levels of a kernel or other bare-metal system will not want this (interrupt handlers and bootstrap, mainly).

[emberian]

It would also be interesting to look at what patterns we have that force use of the unsafe stack (if any) and how to avoid that.

[Aatch]

@cmr looking at the CPI paper, any stack-allocated value that has its address taken. That's actually fairly common in Rust code, and avoiding it isn't really feasible. I'd be interested in seeing what performance effects it has on Rust code, as the patterns in Rust code are quite different to those in C/C++.

[bstrie]

The SafeStack commit message says that the safe stack can contain "local variables that are statically verified to be accessed in a safe way". Are our notions of safety stronger than what LLVM considers to be "safe" here, meaning that basically all variables would be living in the safe stack?

[lambda]

Posted this in the Reddit thread, but this might be a better place to leave it.

It looks like the way this determines 'safe' vs 'unsafe' is by looking at how a function uses a pointer returned by alloca.

The code that check this looks like it basically whitelists a few safe operations, such as dereferencing the pointer directly, using a constant index into a constant sized array, and passing it in to arguments of functions annotated with nocapture (which seems like a somewhat dubious choice, as it seems like there's plenty unsafe that a function could do without capturing a pointer).

It doesn't look like there's any way to whitelist any potential uses, other than using nocapture for arguments to functions. Searching through the Rust source, it doesn't look like nocatpure is currently applied except in one specialized case; in some of the tests, there is a TODO indicating that it should probably be applied in more cases.

So, I'm guessing that the best thing that Rust could do to give it more information would be applying nocapture to appropriate arguments. However, when doing that, it seems like the guarantess are fairly best-effort, as there's no interprocedural analysis done, so a nocapture argument that eventually gets passed into unsafe code could probably wind up being exploited.

Note that this was just a very cursory look that I took at the code, I could be wrong about how it works.

[emberian]

@lambda Yeah, it looks pretty conservative right now. I suspect many locals would end up on the unsafe stack. Alas.

[alexcrichton]

We updated LLVM so there's support for this in our LLVM, and I think that turning this on by default probably wants some investigation and likely an RFC first, so I'm going to close this for now.