Date: Fri, 27 Jun 2014 11:07:06 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: Alan Cox <alc@rice.edu>, kib@freebsd.org, Oliver Pinter <oliver.pntr@gmail.com>, Shawn Webb <lattera@gmail.com> Subject: Re: Help With ASLR Message-ID: <201406271107.07029.jhb@freebsd.org> In-Reply-To: <20140627132810.GA8396@pwnie.vrt.sourcefire.com> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140627132810.GA8396@pwnie.vrt.sourcefire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, June 27, 2014 9:28:10 am Shawn Webb wrote:
> On Jun 26, 2014 10:32 PM -0500, Alan Cox wrote:
> > Kostik, I'm not sure that I understand what you're saying here. The
> > randomly generated offset is added to the variable "addr" after this
> > block of code has been executed:
> >
> > } else {
> > /*
> > * XXX for non-fixed mappings where no hint is provided or
> > * the hint would fall in the potential heap space,
> > * place it after the end of the largest possible heap.
> > *
> > * There should really be a pmap call to determine a
> > reasonable
> > * location.
> > */
> > PROC_LOCK(td->td_proc);
> > if (addr == 0 ||
> > (addr >= round_page((vm_offset_t)vms->vm_taddr) &&
> > addr < round_page((vm_offset_t)vms->vm_daddr +
> > lim_max(td->td_proc, RLIMIT_DATA))))
> > addr = round_page((vm_offset_t)vms->vm_daddr +
> > lim_max(td->td_proc, RLIMIT_DATA));
> > PROC_UNLOCK(td->td_proc);
> > }
> >
> > So, the point at which the eventual call to vm_map_findspace() starts
> > looking for free space is determined by the randomization, and thus the
> > chosen address will be influenced by the randomization. The first
> > mmap() that I do in one execution of the program will be unlikely to
> > have the same address in the next execution.
> >
> > That said, I think that this block of code would be a better place for
> > the pax_aslr_mmap() call than were it currently resides. Moving it here
> > would address the problem with MAP_32BIT mentioned below.
>
> Did our changes break MAP_32BIT or was MAP_32BIT broken all along? If
> our ASLR patch breaks it, what would be the best way to fix it?
My reading of the above is your changes break it (it certainly worked when I
tested it when it first went in, but it's also a fairly recent addition, as
are the various alignment flags). I believe from the bit quoted above that
Alan would like you to move your call to pax_aslr_mmap() to the code quoted
above.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201406271107.07029.jhb>