Allocate a guard page for each newly created thread

[LemonBoy]

No description provided.

[daurnimator]

This PR no longer relies on the kernel's guard page (it removes MAP_GROWSDOWN) and does it in userland instead.
Doesn't this mean that the stack can no longer grow?

[LemonBoy]

Doesn't this mean that the stack can no longer grow?

Yes, but MAP_GROWSDOWN it's not a good idea. You can easily see that glibc nor musl use it anymore and set-up the guard page by themselves. The main thread stack is still growable and hopefully protected by a large-enough gap.

[daurnimator]

MAP_GROWSDOWN it's not a good idea.

TIL.

The main thread stack is still growable

How does this work if not MAP_GROWSDOWN?
What about other threads?

[LemonBoy]

How does this work if not MAP_GROWSDOWN?

The kernel is still using that flag internally (as VM_GROWSDOWN) but is extra careful in making sure there's no possibility of clashing between stacks and "common" allocations. Rust tried to allocate a guard page for the main thread stack but had to revert that choice, relying on the kernel-provided guard gap is the way to go.

What about other threads?

The whole stack is allocated and a guard page is added, a simple trick that solves so many (security) problems.

[andrewrk]

Is this truly unreachable? My understanding is that this "splits" a mapping which can potentially result in ENOMEM. Fortunately OutOfMemory is one of the possible errors of spawning a thread, so I think we can just return it.