We never have, and that's not what I'm suggesting. In the segmented stack era when we hit the end of the stack we called abort!. A runtime abort does not trigger a segfault, but an illegal instruction. Apparently, the current stack overflow behavior causes the process to exit with a segfault, not an abort. This is incorrect because it is leaking an implementation detail of our stack overflow detection. We should rather trap the segfault and abort like any other fatal error.
No, if the overflow happens, the application will just be aborted because of Rust's stack probing.
This was and is Not a bug. Rust was just exposing internal details(again, by "exposing" I don't mean in a security way, just that it was passing the stack overflow further to the system when it didn't have to) before but it still had the protection.
It is implemented on Windows, but due to lack of LLVM support on other platforms, isn't on some other very major ones. It's blocked on upstream, basically.
That can only happen when you have guard pages without stack probes. With stack probes, whenever you perform a read more than a page down the stack from the last read, you read a byte out of every page in-between to guarantee you never skip over the guard page.
In theory, yes. There are no partially initialized on-stack arrays in the safe Rust subset (as far as I know), but there are some LLVM stack slot reuse optimizations which appear to have a similar effect. As a result, it is theoretically possible that the stack pointer is decremented past the guard page, and execution continues with a stack that overlaps with other (writable) memory.
There can be safe interfaces on top of uninitialized stack data though, like ArrayVec. But since that's still statically sized, maybe it's not much of an exploitation concern. My intuition is that a huge ArrayVec will always fail, whereas you need VLAs to get something that usually works but may overflow when under attack.