SafeStack proposal in GCC
I have noticed this topic in history of gcc ml, how is that going with this feature? I have much interest in this feature and am trying to do sth in these days. There are some questions about the design you mentioned. As my understanding, a single gimple pass is not enough for safestack, for example if an aggregate type arg is passed by reference, it may be copied to a stack slot of caller, and the pointer will be passed to callee, that will break the rule of safestack. So i think we should do something in expand pass or need another pass after expand. Hello, I bring to your attention SafeStack, part of a bigger research project - CPI/CPS [1], which offers complete protection against stack-based control flow hijacks. I am interested in developing SafeStack for GCC and I would like to ask for your feedback on this proposal. SafeStack is a security mechanism that protects against stack based control flow attacks, while also keeping a low runtime overhead - it prevents all stack-based attacks in the RIPE benchmark, and has just 0.05% overhead on average on SPEC CPU2006 benchmarks [2]. Safestack has been recently merged into the Clang/LLVM mainline [3]. Its design is based on the separation of stack-allocated memory objects in two regions: the safe stack, where we keep the return addresses, spilled registers and local variables proved to be only accessed in a safe way by a static analysis pass at compilation, and the regular region, where we move everything else. With this separation and randomized-based isolation of the safe stack, we ensure that no overflows from the unsafe stack can overwrite sensitive data from the safe stack. Further on, the isolation mechanism can be improved to use hardware segment protection or hardware extensions, such as Intel Memory Protection Keys. We aim to extend all of CPI into the GNU userland, but start with a SafeStack port in GCC. In GCC, we propose a design composed of an instrumentation module (implemented as a GIMPLE pass) and a runtime library. The instrumentation pass will perform static analysis to discover stack objects that are only accessed in a safe way. It will also insert code that allocates a stack frame for the rest of the objects, those that did not satisfy the safety condition. The pass will run independently, after GIMPLE lowering, scheduled on the all_passes list and after other optimizations, such as dead code elimination. Then, all accesses to unsafe objects have to be re-written, based on the new stack base and offset in the unsafe stack. In the first phase of the implementation, the unsafe stack will be allocated on the heap, and we will rely on ASLR for the isolation. The runtime support will have to deal with unsafe stack allocation - a hook in the pthread create/destroy functions to create per-thread stack regions. This runtime support might be reused from the Clang implementation. We appreciate your feedback and remarks on this proposal. Thank you, Cristina -- Best Regards Li Kun
Re: SafeStack proposal in GCC
I have noticed this topic in history of gcc ml, how is that going with this feature? I have much interest in this feature and am trying to do sth in these days. There are some questions about the design you mentioned. As my understanding, a single gimple pass is not enough for safestack, for example if an aggregate type arg is passed by reference, it may be copied to a stack slot of caller, and the pointer will be passed to callee, that will break the rule of safestack. So i think we should do something in expand pass or need another pass after expand. Hello, I bring to your attention SafeStack, part of a bigger research project - CPI/CPS [1], which offers complete protection against stack-based control flow hijacks. I am interested in developing SafeStack for GCC and I would like to ask for your feedback on this proposal. SafeStack is a security mechanism that protects against stack based control flow attacks, while also keeping a low runtime overhead - it prevents all stack-based attacks in the RIPE benchmark, and has just 0.05% overhead on average on SPEC CPU2006 benchmarks [2]. Safestack has been recently merged into the Clang/LLVM mainline [3]. Its design is based on the separation of stack-allocated memory objects in two regions: the safe stack, where we keep the return addresses, spilled registers and local variables proved to be only accessed in a safe way by a static analysis pass at compilation, and the regular region, where we move everything else. With this separation and randomized-based isolation of the safe stack, we ensure that no overflows from the unsafe stack can overwrite sensitive data from the safe stack. Further on, the isolation mechanism can be improved to use hardware segment protection or hardware extensions, such as Intel Memory Protection Keys. We aim to extend all of CPI into the GNU userland, but start with a SafeStack port in GCC. In GCC, we propose a design composed of an instrumentation module (implemented as a GIMPLE pass) and a runtime library. The instrumentation pass will perform static analysis to discover stack objects that are only accessed in a safe way. It will also insert code that allocates a stack frame for the rest of the objects, those that did not satisfy the safety condition. The pass will run independently, after GIMPLE lowering, scheduled on the all_passes list and after other optimizations, such as dead code elimination. Then, all accesses to unsafe objects have to be re-written, based on the new stack base and offset in the unsafe stack. In the first phase of the implementation, the unsafe stack will be allocated on the heap, and we will rely on ASLR for the isolation. The runtime support will have to deal with unsafe stack allocation - a hook in the pthread create/destroy functions to create per-thread stack regions. This runtime support might be reused from the Clang implementation. We appreciate your feedback and remarks on this proposal. Thank you, Cristina -- Best Regards Li Kun
[Question]: How to tracking the relationship between gimple expr and expanded rtx ?
I need to known which rtx is expanded from a specific CALL_EXPR, how could i do ? Is INSN_LOCATION accurate enough ? -- Best Regards Li Kun
Re: [Question]: How to tracking the relationship between gimple expr and expanded rtx ?
在 2019/1/18 16:52, Richard Biener 写道: On Fri, Jan 18, 2019 at 4:11 AM Li Kun wrote: I need to known which rtx is expanded from a specific CALL_EXPR, how could i do ? Is INSN_LOCATION accurate enough ? No. There's no accurate way to do this so you have to invent something. Or start by explaining what you are wanting to do. I'm trying to implement safestack as an pass after expand, so i have to known where the args are lying if the composite struct param passed by reference, and i could move the arg to unsafe region. I try to not interfere the procedure of expand_call, but i can't get the accurate informations. What i'm thinking about is to get the rtxs of CALL_EXPR, and to locate the args reversely. So is there any better way to make it ? Thanks a lot! Richard. -- Best Regards Li Kun -- Best Regards Li Kun
