On 5/2/23 22:36, Varun Kumar E via Gcc wrote:
Hello, https://godbolt.org/z/P3M8s8jqh The above case shows that gcc first decreases the stack pointer and then probes. As mentioned by Jeff Law (reference <https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fstack-check-is-not-the-answer#>) under "More issues with -fstack-check". If an asynchronous signal is received between the decrement of stack pointer and probing of the pages. *"In that case, the stack pointer could be pointing beyond the guard into the heap. The signal arrives and the kernel transfers control to the registered signal handler. That signal handler is then running while its stack is pointing into the heap. Thus, the attacker has clashed the stack and heap, and there's a reasonable chance they can gain control over the program" * So, Shouldn't we first probe and if successful only then update the stack pointer? Or Maybe I have understood it incorrectly.
That may ultimately be better for -fstack-check to make it more robust, but it still wouldn't be a viable alternative for stack clash protection for the reasons laid out in that blog post.
jeff
