Re: Nanokernel stack border protection


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

Of course, this wouldn't necessarily catch all stack overflows, specifically those on the unsafe stack.

-----Original Message-----
From: LeMay, Michael [mailto:michael.lemay(a)intel.com]
Sent: Friday, September 30, 2016 15:02
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: Re: Re: Re: Nanokernel stack border protection

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.