Help With ASLR

Shawn Webb lattera at gmail.com
Thu Jun 26 23:27:32 UTC 2014


Hey All,

I've exchanged a few helpful emails with kib at . 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2014-06-21_aslr.patch
Type: text/x-diff
Size: 92921 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140626/cd38c593/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20140626/cd38c593/attachment.sig>


More information about the freebsd-hackers mailing list