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

[Sergey Bugaev]

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?

Sergey