Re: Nanokernel stack border protection


LeMay, Michael <michael.lemay@...>
 

On Mon, 2016-09-26 at 17:33 +0000, Boie, Andrew P wrote:
...
Yeah it's probably a dealbreaker. In C you can take the address of some stack variable and pass it to another function, stack references seem to really need to be on the data segment. Oh well. I think I have to conclude that this kind of stack bounds checking isn't possible on x86 at least in C code.
This is possible on x86 with C. I already have it working for Contiki OS with an enhanced version of LLVM/Clang. It relies in part on the LLVM SafeStack pass that defines a separate "unsafe stack" for allocations that the compiler is unable to verify are accessed safely (http://clang.llvm.org/docs/SafeStack.html). So, only stack allocations that the compiler verifies are accessed safely are placed on the main/safe stack. I developed a patch for Contiki OS to place tight bounds around the safe stack in SS. I configured CS, DS, ES, FS, and GS to not overlap with SS, and I placed the unsafe stack in DS. I dealt with the challenge of handling stack references passed between functions by modifying the SafeStack pass to move all allocations used in that way to the unsafe stack (https://reviews.llvm.org/D17094). The compiler can then assume that no pointers to the safe stack are passed as function arguments. Safe stack pointers are only generated locally, within the same function that uses those pointers. There are some exceptions to this, like variadic argument lists, but those are handled specially. Based on the assumption that safe stack pointers are all generated and used within a function, I developed a new compiler pass that tracks the flow of safe stack pointers within a function (https://reviews.llvm.org/D17095, https://reviews.llvm.org/D17092). It adds segment override prefixes as necessary to direct memory accesses to the appropriate segments.

Join devel@lists.zephyrproject.org to automatically receive all group messages.