On Tue, Jul 26, 2016 at 07:57:45PM +0000, Roberts, William C wrote: > > > > -----Original Message----- > > From: Kirill A. Shutemov [mailto:kirill@xxxxxxxxxxxxx] > > Sent: Tuesday, July 26, 2016 12:26 PM > > To: Roberts, William C <william.c.roberts@xxxxxxxxx> > > Cc: linux-mm@xxxxxxxxx > > Subject: Re: [PATCH] [RFC] Introduce mmap randomization > > > > On Tue, Jul 26, 2016 at 11:27:11AM -0700, william.c.roberts@xxxxxxxxx wrote: > > > From: William Roberts <william.c.roberts@xxxxxxxxx> > > > > > > This patch introduces the ability randomize mmap locations where the > > > address is not requested, for instance when ld is allocating pages for > > > shared libraries. It chooses to randomize based on the current > > > personality for ASLR. > > > > > > Currently, allocations are done sequentially within unmapped address > > > space gaps. This may happen top down or bottom up depending on scheme. > > > > > > For instance these mmap calls produce contiguous mappings: > > > int size = getpagesize(); > > > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x40026000 > > > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x40027000 > > > > > > Note no gap between. > > > > > > After patches: > > > int size = getpagesize(); > > > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x400b4000 > > > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > > 0x40055000 > > > > > > Note gap between. > > > > And why is it good? > > Currently if you get an info leak and discover, say the address to libX > It's just a matter of adding/subtracting a fixed offset to find libY. This > will make rop a bit harder if you're trying to rop into a different library > than what was leaked. > > This also has a benefit outside of just libraries in that it randomizes all the > Mappings done via mmap from run to run. So you don't get consistent, > known offsets to things within the memory space. > > > > > > Using the test program mentioned here, that allocates fixed sized > > > blocks till exhaustion: > > > https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html, > > > no difference was noticed in the number of allocations. Most varied > > > from run to run, but were always within a few allocations of one > > > another between patched and un-patched runs. > > > > > > Performance Measurements: > > > Using strace with -T option and filtering for mmap on the program ls > > > shows a slowdown of approximate 3.7% > > > > NAK. > > > > It's just too costly. And no obvious benefits. > > Sorry I used to have the explanation in the message, a carless edit > removed it. > > The cost does suck, perhaps something like personality + KConfig option.... Cost sucks even more than you've mentioned: you'll pay on every page fault, as find_vma() would have more vmas in the tree and vmacache will not be that effective. That's something people spend a lot time to tune. Taking this into account, I can't see any real-world application that would opt-in for this security feature. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>