From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 27 15:51:44 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ECDBB30; Fri, 27 Jun 2014 15:51:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 744192D80; Fri, 27 Jun 2014 15:51:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50154B9C1; Fri, 27 Jun 2014 11:51:43 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Help With ASLR Date: Fri, 27 Jun 2014 11:07:06 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> <53ACE5B4.8070700@rice.edu> <20140627132810.GA8396@pwnie.vrt.sourcefire.com> In-Reply-To: <20140627132810.GA8396@pwnie.vrt.sourcefire.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201406271107.07029.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 27 Jun 2014 11:51:43 -0400 (EDT) Cc: Alan Cox , kib@freebsd.org, Oliver Pinter , Shawn Webb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 15:51:44 -0000 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