Re: git: 21e45c30c35c - main - mmap(MAP_STACK): on stack grow, use original protection

On Thu, Jul 20, 2023 at 11:49:21PM +0300, Konstantin Belousov wrote:
> On Thu, Jul 20, 2023 at 08:15:15PM +0000, Brooks Davis wrote:
> > On Thu, Jul 20, 2023 at 02:12:13PM +0000, Konstantin Belousov wrote:
> > > The branch main has been updated by kib:
> > > 
> > > URL: https://cgit.FreeBSD.org/src/commit/?id=21e45c30c35c9aa732073f725924caf581c93460
> > > 
> > > commit 21e45c30c35c9aa732073f725924caf581c93460
> > > Author:     Konstantin Belousov <kib@FreeBSD.org>
> > > AuthorDate: 2023-07-19 11:05:32 +0000
> > > Commit:     Konstantin Belousov <kib@FreeBSD.org>
> > > CommitDate: 2023-07-20 14:11:42 +0000
> > > 
> > >     mmap(MAP_STACK): on stack grow, use original protection
> > >     
> > >     If mprotect(2) changed protection in the bottom of the currently grown
> > >     stack region, currently the changed protection would be used for the
> > >     stack grow on next fault.  This is arguably unexpected.
> > >     
> > >     Store the original protection for the entry at mmap(2) time in the
> > >     offset member of the gap vm_map_entry, and use it for protection of the
> > >     grown stack region.
> > 
> > It occured to me to wonder how this interacts with
> > __enable_execute_stack().  I think it's ok so long as the compiler
> > always emits __enable_execute_stack() for each trampoline and doesn't
> > depend on extentions to the stack being executable from the first
> > trampoline creation, but I don't know where to look to verify that's the
> > case.
> Even on first trampoline creation, compiler cannot know how much was the
> stack grown already.  So the generated code cannot be sure that it changing
> the protection for the bottom stack page.  Then, it cannot work even for
> more usual stack grow organization.

That makes sense.  Thanks for the clarification.

-- Brooks