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

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 20 Jul 2023 20:49:21 UTC
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.