Re: Help With ASLR


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
>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"