How does the stack's guard page work on amd64?

[Konstantin Belousov]

On Mon, Mar 29, 2021 at 11:06:36PM -0600, Alan Somers wrote:
> Rust tries to detect stack overflow and handles it differently than other
> segfaults, but it's currently broken on FreeBSD/amd64.  I've got a patch
> that fixes the problem, but I would like someone to confirm my reasoning.
> 
> It seems like FreeBSD's main thread stacks include a guard page at the
> bottom.  However, when Rust tries to create its own guard page (by
> re-mmap()ping and mprotect()ing it), it seems like FreeBSD's guard page
> automatically moves up into the un-remapped region.  At least, that's how
> it behaves, based on the addresses that segfault.  Is that correct?
Show the facts. For instance, procstat -v (and a note which
mapping was established by runtime for the 'guard') would tell the whole
story.

My guess would be that procctl(PROC_STACKGAP_CTL, &PROC_STACKGAP_DISABLE)
would be enough.  Cannot tell without specific data.

> 
> For other threads, Rust doesn't try to remap the guard page, it just relies
> on the guard page created by libthr in _thr_stack_alloc.
> 
> Finally, what changed in between FreeBSD 10.3 and 11.4?  Rust's stack
> overflow detection worked in 10.3.
> 
> -Alan
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"