[PATCH] ld.so: Always use MAP_COPY to map the first segment [BZ #28656]

[H.J. Lu]

On Thu, Jun 15, 2023 at 8:42 AM Sergey Bugaev <bugaevc@gmail.com> wrote:
>
> On Thu, Jun 15, 2023 at 6:23 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Wed, Jun 14, 2023 at 1:32 AM Sergey Bugaev <bugaevc@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > On Tue, June 13, 2023 at 8:19 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > > To support LD_PREFER_MAP_32BIT_EXEC, we pass MAP_32BIT to mmap when the
> > > > first segment in a shared library is mapped with MAP_DENYWRITE.  But if
> > > > the segment alignment is greater than the page size, MAP_DENYWRITE isn't
> > > > used to map the first segment. In this case, we should map the first
> > > > segment with MAP_COPY, instead of MAP_PRIVATE, which is defined as
> > > >
> > > >  # define MAP_COPY      (MAP_PRIVATE | MAP_DENYWRITE)
> > >
> > > isn't MAP_DENYWRITE ignored by Linux? So this change wouldn't make any
> > > difference on Linux, would it?
> >
> > MAP_DENYWRITE is ignored by Linux kernel.   Glibc for Linux checks
> > MAP_DENYWRITE to decide if MAP_32BIT should be used.
>
> Ahh, I see, thanks. That wasn't clear from the commit message,
> although now I see where it says that.
>
> Something like this would have been clear to me:
>
> "When prefer_map_32bit_exec is enabled, mmap determines whether to use
> MAP_32BIT by checking for (prot & PROT_EXEC) and also for
> (flags & MAP_DENYWRITE). The latter is needed to also set MAP_32BIT for
> the first segment in a shared library in case it's not marked executable
> due to -z separate-code. But if ..."
>
> My prefer_map_32bit_exec implementation for the Hurd only checks for
>
> (addr == NULL) && (prot & PROT_EXEC)
>
> should I be checking for MAP_COPY as well?
>

I think so.

H.J.