[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] exec: Properly preallocate address space

From: Sergey Bugaev
Subject: Re: [PATCH 4/4] exec: Properly preallocate address space
Date: Mon, 3 Jul 2023 11:19:54 +0300

On Mon, Jul 3, 2023 at 2:48 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Sergey Bugaev, le lun. 26 juin 2023 02:11:37 +0300, a ecrit:
> > @@ -1297,17 +1274,6 @@ do_exec (file_t file,
> >        finish (&interp, 1);
> >      }
> >
> > -
> > -  /* Leave room for mmaps etc. before PIE binaries.
> > -   * Could add address randomization here.  */
> > -  anywhere_start += 128 << 20;
> This doesn't seem to appear any more in the result?

I dropped it because I couldn't understand how it is useful; perhaps
you could explain?

> We need this area for mmap to go somewhere that hopefully doesn't
> conflict with the brk.

But the brk is at a fixed high address (BRK_START), why would it
conflict with mmaps? 'man brk' says "the program break is the first
location after the end of the uninitialized data segment", but that's
just not true, at least not on the Hurd. As long as gnumach always
allocates the lowest available range of suitable size, allocations
should never conflict with the brk. This would be an issue with ASLR

Is there a specific program that breaks that I could test this with?

On another note, I don't understand what brk is doing in modern
systems (ones that have mmap) at all. It would indeed make some sense
to use the remainder of the last page allocated to host the executable
to place your initial heap there, but that does not need any syscalls
(since the page is already allocated, and that's the whole point), and
that's not how it works on the Hurd. I wonder if anything would break
(hah!) if we just dropped brk completely, and always relied on mmap.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]