16 ms·

LLVM merges SafeStack

• VeejayRampay 11y ago
  From the article: "The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks)". That's quite awesome, congratulations.
  • vanderZwan 11y ago
    Especially if you add the follow-up sentence: "This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies." Win-win for everyone
• joosters 11y ago
  The performance is impressive, considering that maintaining a second stack presumably requires another register exclusively dedicated to it. I'm surprised it makes such little difference. Or are there some cunning optimisations going on?
  • sanxiyn 11y ago
    Safe stack gets a dedicated register, unsafe stack does not. Then the problem is to keep as much as possible on safe stack.
  • evanpw 11y ago
    I was wondering the same thing. The linked article (http://dslab.epfl.ch/pubs/cpi.pdf http://dslab.epfl.ch/pubs/cpi.pdf) says that they don't use a dedicated register. The unsafe stack pointer is saved in the thread control block, accessible through a segment register. From there, they let LLVM choose a register (not necessarily the same one for each function). They also say that only 25% of functions need any unsafe stack access at all, which I guess is why this is faster than using a dedicated register.
  • tomp 11y ago
    Essentially, what they are doing is allocating all unsafe objects (i.e. arrays and objects whose pointer is passed to another function) on a dedicated region of the heap (that they call the unsafe stack) that only keeps these objects, so all (de-)allocation happens in the LIFO order and can be implemented as a stack. As pointed out by evanpw, they keep a pointer to this region in the thread-local store.
  • moyix 11y ago
    From the paper: > This is because objects that end up being moved to the regular (unsafe) stack are usually large arrays or variables that are used through multiple stack frames. Moving such objects away from the safe stack increases the locality of frequently accessed values on the stack, such as CPU register values temporarily stored on the stack, return ad- dresses, and small local variables. I wonder if this speedup effectively hides the performance overhead of SafeStack.
• ekr 11y ago
  Does this mean that it will no longer be possible to do things like return-oriented programming? LE: indeed, it's quite clear from the mentioned article (http://dslab.epfl.ch/pubs/cpi.pdf http://dslab.epfl.ch/pubs/cpi.pdf). So this provides great exploit protection.
  • agumonkey 11y ago
    Accidentally downvoted you. My apologies.
    • viraptor 11y ago
      Upvoted for you.
    • VMG 11y ago
      If only there was a way to space those two tiny arrows further apart. Let's hope science comes up with a way some day..
      • agumonkey 11y ago
        HN is a mind hack to exercise your jquery skills.
        • kbenson 11y ago
          The best explanation I've heard for HN's lack of some features is that any HN power user is expected to find a solution for these problems. That doesn't necessarily mean making a solution, it may just entail searching for a third party solution, or discovering a bit of specific HN behavior that isn't well documented. I imagine any user with over 1000 karma probably has at least a few tricks, and could mention off the top of their head a few things that help quite a bit when using the site. At the same time, I think it's best they aren't mentioned too often, as they offer a sort of natural advantage to those that have been around an while and contributed to discussions (it's the nature of many of these helpers that they actually help discussion), and putting those tools into the hands of a novice user may actually be detrimental to the site as a whole.
• willvarfar 11y ago
  Apple, which has started distributing LLVM bitcode, will be able to apply it on all the new apps in the App Store transparently. Google will be able to do likewise for NaCL apps.
  • coldtea 11y ago
    >Google will be able to do likewise for NaCL apps All 5 of them?
  • minthd 11y ago
    >>Google will be able to do likewise for NaCL apps. They might be able to apply that over all of android - and that will automatically apply over java based apps.From there it's just a matter of incentives, to rapidly create change in rest of the apps.
  • higherpurpose 11y ago
    Apple is making its apps LLVM-based now? Doesn't that mean they could soon push for ARM CPUs in Mac OS, too?
    • willvarfar 11y ago
      It means exactly that. Here's a nice article describing it: > This means that apps can automatically “take advantage of new processor capabilities we might be adding in the future, without you re-submitting to the store.” http://thenextweb.com/apple/2015/06/17/apples-biggest-developer-news-at-wwdc-that-nobodys-talking-about-bitcode/ http://thenextweb.com/apple/2015/06/17/apples-biggest-develo...
      • vsl 11y ago
        It doesn't. Bitcode is arch specific and unportable. It allows some instruction-set level optimizations, but not changing e.g. endianness (exactly what x64 and arm differ in) or type sizes.
        • 11y ago
• arielby 11y ago
  IA-64 had this since it was created - nice to see it coming to x86.
• wang_li 11y ago
  Now if we can get the stack to grow upwards instead of downwards my life will be complete and I can die.
• extropy 11y ago
  Why don't we have a CPU architecutre with two stacks - one for stack data and another for return addresses?
  • MichaelGG 11y ago
    Or write code in languages that, you know, don't encourage unwanted arbitrary code execution?
  • arielby 11y ago
    That's what SafeStack (and IA-64) do.
• thisismyhaendel 11y ago
  To be clear: SafeStack does NOT prevent return oriented programming. It makes the bar much higher, and it should be lauded for that. But please don't for a second think that this is a solved problem: ROP can occur on the heap, for instance. CPI as a system also does not completely solve the problem: it is possible to break, for example (http://web.mit.edu/ha22286/www/papers/conference/Oakland15.pdf http://web.mit.edu/ha22286/www/papers/conference/Oakland15.p... ) and despite the CPI author's conclusions, produces high overheads for programs with large amounts of code pointers (C++ programs with vtables are good examples). Also not prevented are attacks that use data pointers (non control-flow data attacks), an area that has seen little study.
  • thisismyhaendel 11y ago
    Also see papers like BlindROP: http://www.scs.stanford.edu/~sorbo/brop/bittau-brop.pdf http://www.scs.stanford.edu/~sorbo/brop/bittau-brop.pdf and Sigreturn oriented programming: https://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf https://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf to get a little bit more of the idea of how complicated ROP can actually get.
• __michaelg 11y ago
  This demonstrates one of the strengths of compiler frameworks: once the feature is available in LLVM, lots of compilers and VMs can use it easily, even newer ones like Rust or Microsoft's LLILC.
• comex 11y ago
  Interesting. I haven't fully digested the paper, but a few notes for context: - Most real-world exploits these days are based on use-after-frees, heap buffer overflows, and other heap-related weirdness, rather than stack buffer overflows. It's nice that SafeStack mitigates that attack vector though (but if you disable stack canaries in favor of it, you actually reopen the door to exploit certain types of vulnerabilities...) - A (the most?) common method to proceed from memory corruption to return-oriented programming is to redirect a virtual method call or other indirect jump to a stack pivot instruction. SafeStack alone does nothing to prevent this, so it doesn't prevent ROP. - However, the general code-pointer indirection mechanisms described in the paper, of which SafeStack is an important component, could make ROP significantly harder, because you would only be able to jump to the starts of functions. This guarantee is similar to Windows's CFG (although the implementation is different), but SafeStack makes it harder to bypass by finding a pointer into the stack (either on the heap or via gadget). - In practice, interoperation with unprotected OS libraries is likely to seriously compromise the security benefits of the combined scheme, because they will store pointers into the real stack, jump directly to code pointers on the heap, etc. JIT compilers are also likely to be problematic. - In addition, there are more direct ways for an attacker to work around the protection, such as using as gadgets starts of functions that do some small operation and then proceed to a virtual call on an argument. The larger the application, the more possibilities for bypass there are. - Still, "harder" is pretty good. Edit: By the way, the point about function start gadgets makes questionable the paper's claim that "CPI guarantees the impossibility of any control-flow hijack attack based on memory corruptions." Also, if you want to guarantee rsp isn't leaked, it isn't enough to keep all pointers near it out of regular memory: they also have to be kept out of the stack itself, because functions with many (or variable) arguments will read them from the stack - at least, I don't see a claim in the paper about moving them - so subverting an indirect call to go to a function that takes more arguments than actually provided (or just changing a printf format string to have a lot of arguments) will cause whatever data's on the stack to be treated as arguments. Ditto registers that either can be used for arguments or are callee-saved. That means frame pointers have to be disabled or munged, and any cases where LLVM automatically generates temporary pointers for stack stores - which I've seen it do before - have to be addressed. If you do move non-register arguments to the safe stack then the situation is improved, but you still have to watch out for temporaries left in argument registers.
• hughw 11y ago
  It never occurred to me before to ask, but aren't Emscripten asm.js programs vulnerable to the same exploits C programs are? e.g. I could exploit a buffer overflow in some trusted js code to get some sensitive information from the site. If that's the case, would emcc with SafeStack mitigate that?