[LLVMdev] [PROPOSAL] Adding support for -fstack-protector-strong
Joshua.Magee at am.sony.com
Wed Oct 3 19:01:41 PDT 2012
At 1349203977 seconds past the Epoch, John Criswell wrote:
> If you're looking for a project to learn about LLVM and Clang, then I
> think this is a great project. If the LLVM /Clang community wants this
> feature so that it is feature-compatible with GCC, then I think
> including this feature into LLVM/Clang makes sense.
Yes, this is one reason - it seems like a reasonable project to get more
involved with the LLVM and Clang community. The other reason is that
this feature has been requested by developers at my place-of-work.
> If you want to protect applications from attack, then I think there are
> far more productive and interesting things to work on than stack
> protectors. Stack protectors are really a hack and, at best, only
> protect against a single kind of attack (and with buffer overread
> attacks, I'm not even sure if they do that very well). Even if they
> work against stack buffer overflows, stack protectors don't protect the
> application from heap overflows, invalid free attacks, dangling pointer
> attacks, and non-control data attacks.
I agree: Stack protectors only protect against one very specific kind of attack.
> The fastest countermeasure that I think is worth looking at is Control
> Flow Integrity (CFI); CFI adds checks to return instructions and
> indirect jumps to ensure that they're jumping to a valid target
> address. As far as I know, there's no control-hijack attack that works
> against it, although non-control data attacks are still possible. The
> fastest CFI implementation at present has an average overhead of 7.74%
> on 32-bit x86, and by using a very conservative callgraph, you can use
> it without whole program analysis. I've got the LLVM implementation
> from the authors at LeHigh and am updating the code for x86_64 and LLVM
> 3.1 for use in one of my research projects. If you're interested in the
> code, I can ask them if they'd be willing to release the code as
This sounds quite interesting - I'll definitely do some investigation into CFI.
If the authors are willing to release the source code as open-source
that would be great.
> Optimizations for memory safety tools like ASan, SAFECode, and SoftBound
> would be even better since they also stop non-control data attacks.
> Getting good performance out of them is difficult, though, and depending
> on what sorts of overhead you're willing to tolerate, getting good
> performance is still an open research question.
> You might want to check out the memory safety menagerie
> (http://sva.cs.illinois.edu/menagerie). It has lots of papers on
> various techniques and optimizations for those techniques. You might
> find something that will give you the security you want at the
> performance you need.
> In short, I think working on something that provides more comprehensive
> protection is better than working on a partial hack.
> My two (maybe four?) cents.
Thanks for the input. I agree that there are better security techniques
and countermeasures than SSP. At the end of the day SSP-strong is still
something I want to implement. Still, you have given me some food for
thought and a number of interesting tools and techniques to explore.
More information about the llvm-dev