Date: Fri, 27 Jun 2014 01:51:05 +0200 From: Oliver Pinter <oliver.pntr@gmail.com> To: Shawn Webb <lattera@gmail.com> Cc: pageexec@freemail.hu, freebsd-hackers@freebsd.org, hunger@hunger.hu, kib@freebsd.org, alc@rice.edu Subject: Re: Help With ASLR Message-ID: <CAPjTQNG8VQZRzAw=eBHARG6xqM%2BVSxgTVhG8ZpP0ogr2hGLx0g@mail.gmail.com> In-Reply-To: <20140626232727.GB1825@pwnie.vrt.sourcefire.com> References: <20140626232727.GB1825@pwnie.vrt.sourcefire.com>
next in thread | previous in thread | raw e-mail | index | archive | help
CC PaXTeam, Hunger On 6/27/14, Shawn Webb <lattera@gmail.com> wrote: > Hey All, > > I've exchanged a few helpful emails with kib@. He has glanced over the > ASLR patch we have against 11-CURRENT (which is also attached to this > email as a reference point). He has suggested some changes to the VM > subsystem that I'm having trouble getting my head wrapped around. > > Essentially, he suggests that instead of doing the randomization in > various places like the ELF loader and sys_mmap, we should modify > vm_map_find() in sys/vm/vm_map.c to apply the randomization there. > > Here's his suggestion in full (I hope he doesn't mind me directly > quoting him): > > The mapping address randomization can only be performed in the > vm_map_find(). This is the place where usermode mapping flags are > already parsed, and the real decision for the placement is done, with > all the contextual information collected, the fixed requests are not > passed there. Doing the 'randomization' in vm_mmap() means that the > mmap command must be parsed twice, which presented patch fails to do > in any sane way. Only mappings in the usermode maps should be > randomized. > > Current patch does not randomize the mapping location at all, it only > randomizes the hint address passed from the userspace, which is > completely useless. It also fails to correct the address to honour > the placement flags like MAP_32BIT or MAP_ALIGNMENT_MASK. What must > be done is vm_map_find() requesting vm_map_findspace() for the address > hole of the size of the requested mapping + (number of address bits to > randomize << PAGE_SHIFT). Then, the rng value should be obtained and > final location for the mapping calculated as return value + (rng << > PAGE_SHIFT). > > If no address space hole exists which can satisfy the enlarged > request, either a direct fallback to the initial length should be > performed (I prefer this), or exponential decrease of the length up to > the initial size done, and findspace procedure repeated. > > Also, the vm_map_find() knows about the superpages hint for the > mapping being performed, which allows to not break superpages. When > superpage-aligned mapping is requested, SUPERPAGE_SHIFT (available > from pagesizes[1]) should be used instead of PAGE_SHIFT in the formula > above, and probably, a different amount of address bits in the page > table page level 2 to randomize, selected. > === end of kib@ suggestions === > > I have a few concerns, though: > > 1) vm_map_find is also used when loading certain bits of data in the > kernel (like KLDs, for example); > 2) It's not possible to tell in vm_map_find if we're creating a mapping > for the stack, the execbase, or any other suitable mmap call. We apply > ASLR differently based on those three aspects; > 3) vm_map_find is also used in initializing the VM system upon boot. > What impacts would this cause? > > I would really appreciate any feedback. Thank you in advance for any > help or guidance. > > Thanks, > > Shawn >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPjTQNG8VQZRzAw=eBHARG6xqM%2BVSxgTVhG8ZpP0ogr2hGLx0g>