kern/57711: setrlimit(RLIMIT_STACK) fails to increase usable stack size

[campbell+netbsd%mumble.net@localhost]

>Number:         57711
>Category:       kern
>Synopsis:       setrlimit(RLIMIT_STACK) fails to increase usable stack size
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 20 10:55:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        
>Organization:
The PaxBSD Mprotectation
>Environment:
>Description:
Using setrlimit(RLIMIT_STACK) to increase the current process's stack size by raising the soft rlimit doesn't actually increase the usable stack.

The reason is that exec creates three mappings to set up the stack:

1. the guard region, with PROT_NONE;
2. the noaccess region, with PROT_NONE; and
3. the access region, with PROT_READ|PROT_WRITE.

The sizes of the noaccess and access regions are based on the current soft rlimit at exec time.  However, a 2017 change to PAX (in the service of implementing MAP_REMAPDUP) had the unintended side effect of setting the _maximum_ protection to be the same as the current protection.  That's correct for the guard region and for the access region, but for the noaccess region it breaks stack resizing: the uvm_map_protect(PROT_READ|PROT_WRITE) internally issued by setrlimit(RLIMIT_STACK) on some subrange of the noaccess region to make it accessible doesn't have any effect (it fails with EACCES), because the maximum protection is PROT_NONE.
>How-To-Repeat:
Use setrlimit(RLIMIT_STACK) to increase the current process image's stack size.

(Note that this change takes effect on the _next_ exec.  It just doesn't take effect on the current process image.)
>Fix:
Yes, please!